-
Notifications
You must be signed in to change notification settings - Fork 194
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # 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.