Skip to content

/rust

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

Printing of the largest and other very large floats is wrong #7030

Closed
jensnockert opened this Issue Jun 9, 2013 · 10 comments

Comments

Assignees
No one assigned
Labels
P-medium
Projects
None yet
Milestone
No milestone
7 participants
@jensnockert @huonw @silene @metajack @catamorphism @pnkfelix @tshepang
@jensnockert
Copy link
Contributor

jensnockert commented Jun 9, 2013

If you run std::float::infinity.next_after(1.0)` you get the following (unexpected result)

=> 179769313486231680088648464220646842686668242844028646442228680066046004606080400844208228060084840044686866242482868202680268820402884062800406622428864666882406066422426822086680426404402040202424880224808280820888844286620802664406086660842040886824002682662666864246642840408646468824200860804260804068888.0

the expected result is actually something like

=> 179769313486231580788648464220646842686668242844028646442228680066046004606080400844208228060084840044686866242482868202680268820402884062800406622428864666882406066422426822086680426404402040202424880224808280820888844286620802664406086660842040886824002682662666864246642840408646468824200860804260804068887.0
@huonw

This comment has been minimized.

Sign in to view
Copy link
Member

huonw commented Jun 9, 2013

Related to #6220.
@silene

This comment has been minimized.

Sign in to view
Copy link

silene commented Jun 12, 2013

All the large floating-point numbers are multiple of 2^971, so the expected result should not be so odd (pun intended). The largest floating-point number is actually:

179769313486231570814527423731704356798070567525844996598917476803157260780028538760589558632766878171540458953514382464234321326889464182768467546703537516986049910576551282076245490090389328944075868508455133942304583236903222948165808559332123348274797826204144723168738177180919299881250404026184124858368

@jensnockert jensnockert referenced this issue Jul 8, 2013

Closed

Inexact results from str::float::from_str #7648

@metajack

This comment has been minimized.

Sign in to view
Copy link
Contributor

metajack commented Aug 26, 2013

triage bump. i think one of these bugs should be production ready. nominating this one.
@catamorphism

This comment has been minimized.

Sign in to view
Copy link
Contributor

catamorphism commented Sep 5, 2013

Accepted for production-ready
@pnkfelix

This comment has been minimized.

Sign in to view
Copy link
Member

pnkfelix commented Mar 20, 2014

With a heavy heart, not tagging as 1.0 blocker.

P-high, not 1.0.

@pnkfelix pnkfelix added P-high and removed P-high-untriaged labels Mar 20, 2014

@thestinger thestinger referenced this issue Dec 11, 2014

Closed

Numbers are not printed correctly #19752

@pnkfelix pnkfelix referenced this issue Apr 18, 2015

Closed

Float printing and/or parsing is inaccurate #24557

@lifthrasiir lifthrasiir referenced this issue Apr 19, 2015

Merged

New floating-to-decimal formatting routine #24612

1 of 3 tasks complete
@tshepang

This comment has been minimized.

Sign in to view
Copy link
Contributor

tshepang commented Apr 20, 2015

@pnkfelix why is this not a 1.0 blocker?
@pnkfelix

This comment has been minimized.

Sign in to view
Copy link
Member

pnkfelix commented Apr 20, 2015

@tshepang because at the time of that triage, we decided it would be acceptable to fix this after 1.0

As in, we were not saying we cannot fix it; just that we would not wait for perfection before releasing 1.0

I do hope the recently posted flt2dec PR gets into 1.0
@tshepang

This comment has been minimized.

Sign in to view
Copy link
Contributor

tshepang commented Apr 20, 2015

@pnkfelix what I wanted to know is why this was decided. For example, is the fix hard and/or time consuming?
@pnkfelix

This comment has been minimized.

Sign in to view
Copy link
Member

pnkfelix commented Apr 20, 2015

Yes, fixing this properly is hard. See PR #24612 for a taste of the difficulty
@tshepang

This comment has been minimized.

Sign in to view
Copy link
Contributor

tshepang commented Apr 20, 2015

@pnkfelix thanks

bors added a commit that referenced this issue May 9, 2015

@bors
Auto merge of #24612 - lifthrasiir:flt2dec, r=pnkfelix 
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).
d8b3a6a

bors added a commit that referenced this issue May 9, 2015

@bors
Auto merge of #24612 - lifthrasiir:flt2dec, r=pnkfelix 
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).
Loading status checks…
67ba6dc

@bors bors closed this in #24612 May 9, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.