Skip to content
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

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!

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

Successfully merging this pull request may close these issues.

Infinite not being used
3 participants