Ancestors

Toot

Written by soc on 2024-08-26 at 11:05

Would be interesting to declare bankruptcy on f32 and f64, define F32 and F64 types, and implement Id for them.

No support from the derive attribute without hacking the compiler though.

[#]rust

=> More informations about this toot | More toots from soc@chaos.social

Descendants

Written by chrysn on 2024-08-26 at 11:35

@soc What's so troublesome about them? If it's just about NaN, I usually either want / don't care about the IEEE behavior (NaN != NaN), or I want to be sure on the type level there are no NaNs, and some newtype of https://crates.io/crates/typed_floats or similar provides more trait implementations for those.

=> More informations about this toot | More toots from chrysn@chaos.social

Written by soc on 2024-08-26 at 11:42

@chrysn Rust's Eq and Ord hierarchies are a mess in general.

There are some workarounds like the one you mentioned, but they feel more hacky that just implementing what the IEEE 754 standard specifies.

=> More informations about this toot | More toots from soc@chaos.social

Written by Tom on 2024-08-26 at 12:00

@soc @chrysn (maintainer of typed floats here) to be specific, this crate tells you at compile time the possibility of having an NaN, while still respecting the original behaviour. Thus allowing the implementation of Ord and others when possible.

=> More informations about this toot | More toots from tdelmas

Written by soc on 2024-08-26 at 13:14

@tdelmas @chrysn I understand what the crate does, but I'm not looking for a manual solution – I want things to work out-of-the-box.

=> More informations about this toot | More toots from soc@chaos.social

Written by chrysn on 2024-08-26 at 12:01

@soc As far as I understand IEEE 754 specifies that NaN != NaN even for identical values, and that seems to imply that IEEE 754 equality is not reflective, and that requires all Ord/Eq to have a Partial version (which from a mathematical point of view sounds like the right thing to do).

=> More informations about this toot | More toots from chrysn@chaos.social

Written by soc on 2024-08-26 at 13:11

@chrysn Read the standard, it will clear things up for you.

=> More informations about this toot | More toots from soc@chaos.social

Written by chrysn on 2024-08-26 at 13:23

@soc I did, and opened it up again to refresh my memory: compareQuietEqual as described in IEEE 754-2008 section 5.11 looks like the exact pattern for a PartialOrt and PartialEq. (The standard has a lot of signaling in there too, which Rust does not do AFAICT, but that's probably not what you mean either).

I keep reading that people consider think it is messy, but I haven't seen anyone point me to a description of what is wrong, just that it's complex (and that comes from being floats).

=> More informations about this toot | More toots from chrysn@chaos.social

Written by soc on 2024-08-26 at 13:26

@chrysn Scroll up half a page and read 5.10.

=> More informations about this toot | More toots from soc@chaos.social

Written by chrysn on 2024-08-26 at 14:04

@soc So the proposal is to not use compareQuietEqual (and the other comparison operations) to define Rust's == (etc), but to define Rust's relations in terms of totalOrder (possibly exposing compareQuietEqual as a .strict_equals() function)? That's something I could get behind.

=> More informations about this toot | More toots from chrysn@chaos.social

Written by soc on 2024-08-26 at 14:09

@chrysn No.

Using 5.11 for PartialEq/PartialOrd is fine, and the operators Rust uses are in line with the standard.

The only change is to not have Eq/Ord extend the partial ones, so that they can implement 5.10.

(Alternatively define new ones i. e. Id/Srt. It's all hypothetical anyway.)

Then everyone can pick the semantics appropriate for their use-case, without hacks or workarounds.

=> More informations about this toot | More toots from soc@chaos.social

Written by chrysn on 2024-08-26 at 14:18

@soc Thanks for elaborating.

If altering the behavior does not work out, it'd sound tempting to have an IntoOrd trait, and <f32 as IntoOrd>::Generalized = FloatWithOrdFromTotalOrder<f32>, so that at least tools (BTree etc) that care little about whether the Ord makes sense could wrap their inputs automatically -- but then, that would need to be present automatically for everything that does implement Ord, and I don't see how that would work.

=> More informations about this toot | More toots from chrysn@chaos.social

Written by soc on 2024-08-26 at 16:22

@chrysn Probably better to admit defeat, throw some includes method on types that previously had contains with PartialOrd, and then copy-paste map/set std types (i. e. the ones that cannot be fixed) into your own library with proper bounds.

Or break the subtyping relationship between PartialEq/PartialOrd and Eq/Ord, but let the compiler try and patch up the incompatibilities. 😅

In the end I have my language where this all works correctly, so dealing with Rust is not my priority.

=> More informations about this toot | More toots from soc@chaos.social