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

Whether floating point value Display should adhere to IEEE standard? #79490

Closed
crlf0710 opened this issue Nov 28, 2020 · 4 comments
Closed

Whether floating point value Display should adhere to IEEE standard? #79490

crlf0710 opened this issue Nov 28, 2020 · 4 comments
Labels
A-floating-point Area: Floating point numbers and arithmetic I-needs-decision Issue: In need of a decision. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.

Comments

@crlf0710
Copy link
Member

It was raised in #78618 that there needs conscious on whether f32/f64 Display should adhere to IEEE standard, for example outputting +0 instead of more conventional 0.

This issue is created to track this.

@crlf0710 crlf0710 added A-floating-point Area: Floating point numbers and arithmetic T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. I-needs-decision Issue: In need of a decision. labels Nov 28, 2020
@programmerjake
Copy link
Member

From what I can tell, the controversial part was having format!("{}", -0.0) produce "-0" instead of "0" as required by IEEE 754 to preserve the sign of zeros when round-tripping f32/f64 -> String -> f32/f64. Producing "+0" when formatting +0.0 is unnecessary for compliance with IEEE 754 because the sign for "0" is already parsed as positive.

@joshtriplett
Copy link
Member

Personally, I think printing -0.0 as -0 seems reasonable. If you end up with a negative zero, it seems reasonable to support round-tripping that.

@bstrie
Copy link
Contributor

bstrie commented Mar 10, 2021

Related to #72676 .

@joshtriplett
Copy link
Member

We discussed this in the @rust-lang/libs meeting today. We had consensus that changing floating-point printing to print the negative sign on -0 seems reasonable. We don't expect that to cause a problem in practice.

Please go ahead with the PR. We would like to see that PR go through a libs FCP for confirmation when it's ready.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-floating-point Area: Floating point numbers and arithmetic I-needs-decision Issue: In need of a decision. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

4 participants