Panic on sort of f32:s with f32::total_cmp in 1.81.0

just an extra note ...

unless I missed something, even Eq is not sufficient for cache, you need something stronger, e.g.:

assert!(0.0 == -0.0);
assert!(1.0/0.0 != 1.0/(-0.0));

This would have far worse consequences than cache misses.

I have reread the docs and did not found anything that would prevent differently behaved values compare as equal, even for Eq.

2 Likes

Just tossing out my previous research code that uses float for a counting dictionary: internet_route_verification/scripts/src/main.rs at 178d932408201bd299f4368e92066628d4cc7640 · SichangHe/internet_route_verification · GitHub

Just so you know, this kind of things have been working and useful.

By the way, clippy has a lint for this kind of bug:

error: you are implementing `Ord` explicitly but have derived `PartialOrd`
  --> src/lib.rs:5:1
   |
5  | / impl Ord for SortF32 {
6  | |     #[inline(always)]
7  | |     fn cmp(&self, other: &Self) -> std::cmp::Ordering {
8  | |         self.0.total_cmp(&other.0)
9  | |     }
10 | | }
   | |_^
   |
note: `PartialOrd` implemented here
  --> src/lib.rs:1:41
   |
1  | #[derive(Copy, Clone, Debug, PartialEq, PartialOrd)]
   |                                         ^^^^^^^^^^
   = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#derive_ord_xor_partial_ord
   = note: `#[deny(clippy::derive_ord_xor_partial_ord)]` on by default
   = note: this error originates in the derive macro `PartialOrd` (in Nightly builds, run with -Z macro-backtrace for more info)
9 Likes

Do you have to use a float here? There is an excellent rust_decimal crate on crates.io:
rust_decimal - Rust

1 Like

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.