On choosing between decorum and ordered_float

I find myself needing to order some floats. Searches throw up two pre-packaged solutions:

  • ordered-float

    • version 2.2
    • 1 million recent downloads
    • last update 12 days ago
    • no documentation
    • spartan interface
    • I've spent too much time failing to wrap an f64 in NotNaN and not understanding how/why its creation differs from OrderedFloat which Just Works.
  • decorum

    • version 0.3.1
    • 2000 recent downloads
    • last update 12 months ago
    • documented
    • expressive interface
    • Initial experiments throw up no surprises.

Thus, from my naive and ill-informed perspective, ordered-float seems to be the obviously-named, mature, actively-maintained product that everyone uses; and yet decorum, though cryptically-named, seems to be better thought out, better documented and more usable.

As this is a third-order speed bump I'm encountering while trying to achieve something else, I don't really have time study this in depth on my own, right now.

Can you offer any wisdom on the pros and cons of these (or any other options) when it comes to ordering floats in Rust?

1 Like

I did come across this dilemma before, and what made me finally switch from Decorum to ordered-float is the fact that it contains more std trait impls and is therefore easier to work with. IIRC it also returns Result instead of panicking upon NaN, which I find superior, and again, easier to use correctly.

1 Like

Hi, I'm the maintainer of ordered-float. I took over maintenance after the project was abandoned by the original author, because one of my own projects depended on it. However, while I still actively maintain the crate, I no longer use it myself. Most recent improvements have come from other users.

I'll try to take some time to improve the documentation, and of course would be happy to take contributions if there's someone with even more time to do it. I'd also love to hear (in this thread or in the GitHub issue tracker) about any specific things that are missing, confusing, or hard to use.

Thanks also for the pointer to Decorum, which looks interesting. It's unfortunate that it seems abandoned, but if it meets your needs then I don't see any other reasons not to use it.


By the way, the simple way to create a NotNan value if you know the operation can't fail (or if you want it to panic on NAN like Decorum does) is:

let pi = NotNan::new(3.1415).unwrap();

I can add some example code that uses this to the documentation.

1 Like

The latest release (ordered-float 2.3.0) contains some added docs and examples.

More contributions are still welcome, of course!


To throw in another variant, I've heard a bunch of mentions of Noisy_float — Rust math library // Lib.rs too.

Of course, if you just need sorting, you could also ask libs to consider stabilizing fN::total_cmp...

I wonder how to interpret this.

total_cmp is an experimental API in the standard library, so it's not clear to me what it would mean for a lib to stabilize it. Do you mean that library authors might decide/agree to depend on an unstable API?

This probably means Rust libs team. I.e., you could find the relevant tracking issue and try to convince the libs team to push it to the stabilization.

1 Like