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.

Sign up for GitHub

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

Jump to bottom

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

Closed
auroranockert opened this issue Jun 9, 2013 · 10 comments · Fixed by #24612
Closed

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

auroranockert opened this issue Jun 9, 2013 · 10 comments · Fixed by #24612
Labels
P-medium Medium priority

Comments

@auroranockert
Copy link
Contributor

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
Copy link
Member

huonw commented Jun 9, 2013

Related to #6220.

@silene
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

@auroranockert auroranockert mentioned this issue Jul 8, 2013
Closed
@metajack
Copy link
Contributor

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

@catamorphism
Copy link
Contributor

Accepted for production-ready

@pnkfelix
Copy link
Member

With a heavy heart, not tagging as 1.0 blocker.

P-high, not 1.0.

@thestinger thestinger mentioned this issue Dec 11, 2014
Closed
@pnkfelix pnkfelix mentioned this issue Apr 18, 2015
Closed
@lifthrasiir lifthrasiir mentioned this issue Apr 19, 2015
Merged
3 tasks
@tshepang
Copy link
Member

@pnkfelix why is this not a 1.0 blocker?

@pnkfelix
Copy link
Member

@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
Copy link
Member

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

@pnkfelix
Copy link
Member

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

@tshepang
Copy link
Member

@pnkfelix thanks

bors added a commit that referenced this issue May 9, 2015
@bors
Auto merge of #24612 - lifthrasiir:flt2dec, r=pnkfelix
67ba6dc 
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).
flip1995 pushed a commit to flip1995/rust that referenced this issue Apr 8, 2021
@bors
Auto merge of rust-lang#7030 - xFrednet:6877-clippy-going-dark, r=llogiq
6bb608c 
Clippy going dark: Adding a dark theme to Clippy's lint list

This PR adds the MdBook color themes to the lint list of Clippy. Well at least an adaption of these themes.

<details>
<summary>Here are some beautiful screenshots:</summary>

**light theme**
![image](https://user-images.githubusercontent.com/17087237/113510593-e31fb280-955b-11eb-8ab1-8b5bcf287475.png)

**Rust theme**
![image](https://user-images.githubusercontent.com/17087237/113510734-79ec6f00-955c-11eb-981c-8ebe890acf79.png)

**Coal theme**
![image](https://user-images.githubusercontent.com/17087237/113510752-8ec90280-955c-11eb-8f5c-c87ca07c35c2.png)

**Navy theme**
![image](https://user-images.githubusercontent.com/17087237/113510675-3f82d200-955c-11eb-8992-8c784abe19ea.png)

**Ayu theme**
![image](https://user-images.githubusercontent.com/17087237/113510700-588b8300-955c-11eb-83e0-a8f770e9f913.png)

</details>

The theme is also stored in the browser to ensure that the next session applies the theme and doesn't burn your eyes out.

cc: `@matthiaskrgr`

---

Closes rust-lang#6877

changelog: [Clippy's lint list](https://rust-lang.github.io/rust-clippy/master/index.html) now supports themes
flip1995 pushed a commit to flip1995/rust that referenced this issue Apr 8, 2021
@bors
Auto merge of rust-lang#7031 - xFrednet:5234-quick-fix-dark-mode-them…
e315437 
…es, r=llogiq

Quick fix for the updated website theaming to access the correct css files

This fixes a problem from rust-lang#7030 that the service used to access css files was blocked by GitHub pages due to `SSL_ERROR_BAD_CERT_DOMAIN`. The css file loading worked fine during local development. The browser probably disabled some security options due to the local address.

This fix works locally and should also work online as it references the direct css files used by the [mdBook User Guide](https://rust-lang.github.io/mdBook/index.html) the disadvantage of this is that refactorings within the mdBook project can have effects on the theme loading of Clippy. This PR is therefor more meant as a quick fix until I find a better solution.

I've tested these changes using the page editor in the browser and can now confirm that they work :)

changelog: none

r?  `@llogiq`
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
P-medium Medium priority
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

New floating-to-decimal formatting routine lifthrasiir/rust
7 participants
@metajack @auroranockert @pnkfelix @catamorphism @tshepang @huonw @silene