Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

largs floats print slightly wrong #18038

Closed
ben0x539 opened this issue Oct 14, 2014 · 3 comments
Closed

largs floats print slightly wrong #18038

ben0x539 opened this issue Oct 14, 2014 · 3 comments

Comments

@ben0x539
Copy link
Contributor

Lowest roundtripping-integral positive examples I found:

extern {
    fn printf(fmt: *const u8, ...);
}

fn main() {
    let f1: f32 = 41943048_u32 as f32;
    let f2: f64 = 22517998136852488_u64 as f64;
    println!("rust: {}, {}", f1, f2);
    unsafe { printf("c:    %.0f, %.0f\n\0".as_ptr(), f1 as f64, f2); }
}

prints

rust: 41943058, 22517998136852498
c:    41943048, 22517998136852488

We're well past where integers can be roundtripped through floats precisely, but these two examples in particular do roundtrip, so it's weird that we're off by ten when printing them, and anyway C gets it right.

cc #6220?

@emberian
Copy link
Member

cc @lifthrasiir the new "strconv" stuff will fix this.

bors added a commit that referenced this issue May 9, 2015
This is a direct port of my prior work on the float formatting. The detailed description is available [here](https://github.com/lifthrasiir/rust-strconv#flt2dec). In brief,

* This adds a new hidden module `core::num::flt2dec` for testing from `libcoretest`. Why is it in `core::num` instead of `core::fmt`? Because I envision that the table used by `flt2dec` is directly applicable to `dec2flt` (cf. #24557) as well, which exceeds the realm of "formatting".
* This contains both Dragon4 algorithm (exact, complete but slow) and Grisu3 algorithm (exact, fast but incomplete).
* The code is accompanied with a large amount of self-tests and some exhaustive tests. In particular, `libcoretest` gets a new dependency on `librand`. For the external interface it relies on the existing test suite.
* It is known that, in the best case, the entire formatting code has about 30 KBs of binary overhead (judged from strconv experiments). Not too bad but there might be a potential room for improvements.

This is rather large code. I did my best to comment and annotate the code, but you have been warned.

For the maximal availability the original code was licensed in CC0, but I've also dual-licensed it in MIT/Apache as well so there should be no licensing concern.

This is [breaking-change] as it changes the float output slightly (and it also affects the casing of `inf` and `nan`). I hope this is not a big deal though :)

Fixes #7030, #18038 and #24556. Also related to #6220 and #20870.

## Known Issues

- [x] I've yet to finish `make check-stage1`. It does pass main test suites including `run-pass` but there might be some unknown edges on the doctests.
- [ ] Figure out how this PR affects rustc.
- [ ] Determine which internal routine is mapped to the formatting specifier. Depending on the decision, some internal routine can be safely removed (for instance, currently `to_shortest_str` is unused).
@lifthrasiir
Copy link
Contributor

Now fixed by #24612.

@bstrie
Copy link
Contributor

bstrie commented May 10, 2015

Closed by #24612.

@bstrie bstrie closed this as completed May 10, 2015
lnicola pushed a commit to lnicola/rust that referenced this issue Sep 25, 2024
feat: generate names for tuple-struct in add-missing-match-arms

fix rust-lang#18034.

This PR includes the following enhancement:

- Introduced a `NameGenerator` in `suggest_name`, which implements an automatic renaming algorithm to avoid name conflicts. Here are a few examples:

```rust
let mut generator = NameGenerator::new();
assert_eq!(generator.suggest_name("a"), "a");
assert_eq!(generator.suggest_name("a"), "a1");
assert_eq!(generator.suggest_name("a"), "a2");

assert_eq!(generator.suggest_name("b"), "b");
assert_eq!(generator.suggest_name("b"), "b1");
assert_eq!(generator.suggest_name("b2"), "b2");
assert_eq!(generator.suggest_name("b"), "b3");
assert_eq!(generator.suggest_name("b"), "b4");
assert_eq!(generator.suggest_name("b3"), "b5");
```

- Updated existing testcases in ide-assists for the new `NameGenerator` (only modified generated names).
- Generate names for tuple structs instead of using wildcard patterns in `add-missing-match-arms`.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants