-
Notifications
You must be signed in to change notification settings - Fork 191
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
Extended the result of to_f32/to_f64 with infinity #163
Conversation
This PR attempts to solve #161. |
The implementation of `<f64 as ToPrimitive>::to_f32` was written at a time when float-to-float overflow was though to be undefined behavior, per rust-lang/rust#15536, but this was later determined to be fine. Casting a large `f64` to `f32` just results in an infinity with the matching sign. The sign gives more information than if `to_f32` just returns `None`, so now we let these infinities through as a result. See also rust-num/num-bigint#163 and rust-num/num-rational#83.
185: Trust the "i128" feature r=cuviper a=cuviper If the "i128" feature is explicity requested, don't bother probing for it. It will still cause a build error if that was set improperly. 186: Allow large f64-to-f32 to saturate to infinity r=cuviper a=cuviper The implementation of `<f64 as ToPrimitive>::to_f32` was written at a time when float-to-float overflow was though to be undefined behavior, per rust-lang/rust#15536, but this was later determined to be fine. Casting a large `f64` to `f32` just results in an infinity with the matching sign. The sign gives more information than if `to_f32` just returns `None`, so now we let these infinities through as a result. See also rust-num/num-bigint#163 and rust-num/num-rational#83. 190: Normalize the comment style r=cuviper a=cuviper Co-authored-by: Josh Stone <cuviper@gmail.com>
Thanks! bors r+ |
This isn't a complaint on my part, but this change broke some of our code because we relied on "numbers that are too big to be an f32/f64" returning |
Other SOMs that I've tried error (whether deliberately or not) when a big integer is too big to be represented as a floating point number. The `BigInt::to_f64()` function used to return `None` in such cases but now they always return `Some::(f64::INFINITY)` (see rust-num/num-bigint#163). This PR handles that explicitly. On the plus side, we can simplify our code a little bit; on the downside we'll also probably be a tiny bit slower in the common case.
Other SOMs that I've tried error (whether deliberately or not) when a big integer is too big to be represented as a floating point number. The `BigInt::to_f64()` function used to return `None` in such cases but now they always return `Some::(f64::INFINITY)` (see rust-num/num-bigint#163). This PR handles that explicitly. On the plus side, we can simplify our code a little bit; on the downside we'll also probably be a tiny bit slower in the common case.
@ltratt Sorry for the trouble! I debated about the change in behavior myself, but I decided that the sign preservation makes this better than |
No description provided.