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.

Sign up for GitHub

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

Jump to bottom

OrderedFloat comparison with f32/f64 is not total #143

Open
orlp opened this issue Oct 10, 2023 · 1 comment
Open

OrderedFloat comparison with f32/f64 is not total #143

orlp opened this issue Oct 10, 2023 · 1 comment

Comments

@orlp
Copy link
Contributor

orlp commented Oct 10, 2023 •
edited
Loading

Is it intended that OrderedFloat(x) == y where x, y are float types is not a total comparison? This only matters for NaN: OrderedFloat(f32::NAN) == OrderedFloat(f32::NAN) is true, but OrderedFloat(f32::NAN) == f32::NAN is false.

On another note, why is PartialEq<Rhs=T> for OrderedFloat<T> implemented, but the same does not hold true for PartialOrd<Rhs=T> for OrderedFloat<T>?
@mbrubeck
Copy link
Collaborator

Is it intended that OrderedFloat(x) == y where x, y are float types is not a total comparison? This only matters for NaN: OrderedFloat(f32::NAN) == OrderedFloat(f32::NAN) is true, but OrderedFloat(f32::NAN) == f32::NAN is false.

No, I don’t think this is intended; as far as I know we just never thought about which result would be better.

On another note, why is PartialEq<Rhs=T> for OrderedFloat<T> implemented, but the same does not hold true for PartialOrd<Rhs=T> for OrderedFloat<T>?

Also just an oversight, apparently.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@mbrubeck @orlp