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

Extended the result of to_f32/to_f64 with infinity #163

Merged
merged 2 commits into from Oct 30, 2020
Merged

Extended the result of to_f32/to_f64 with infinity #163

merged 2 commits into from Oct 30, 2020

Conversation

ghost
Copy link

@ghost ghost commented Aug 25, 2020

No description provided.

@ghost
Copy link
Author

ghost commented Aug 25, 2020

This PR attempts to solve #161.

cuviper added a commit to cuviper/num-traits that referenced this pull request Aug 28, 2020
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.
bors bot added a commit to rust-num/num-traits that referenced this pull request Oct 29, 2020
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>
@cuviper cuviper linked an issue Oct 30, 2020 that may be closed by this pull request
@cuviper
Copy link
Member

cuviper commented Oct 30, 2020

Thanks!

bors r+

@bors
Copy link
Contributor

bors bot commented Oct 30, 2020

@bors bors bot merged commit da996d1 into rust-num:master Oct 30, 2020
@ghost ghost deleted the infinity branch October 31, 2020 13:10
@ltratt
Copy link

ltratt commented Nov 16, 2020

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 None. I wonder if, perhaps, this might want to be a major release (0.4) rather than a 0.3 point release? FWIW, I think both the original behaviour and the behaviour in this PR are reasonable so I'm not arguing for rolling back the behaviour.

ltratt added a commit to ltratt/yksom that referenced this pull request Nov 16, 2020
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 added a commit to ltratt/yksom that referenced this pull request Nov 16, 2020
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.
@cuviper
Copy link
Member

cuviper commented Nov 16, 2020

@ltratt Sorry for the trouble! I debated about the change in behavior myself, but I decided that the sign preservation makes this better than None. It's already published in 0.3.1, so I don't think we should flip back without a stronger complaint, but I do appreciate your feedback!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Infinite not being used
3 participants