4 ms·

From the docstring for total_cmp `bois.sort_by(|a, b| a.weight.total_cmp(&b.weight));` So yes, but you were already able to use `partial_cmp` before.

by Bromeo 4y ago

pavon 4y ago
Yeah, the difference is that total_cmp can handle NaNs, whereas with partial_cmp you either had to add your own handling, or get panics on NaN if you blindly call partial_cmp.unwrap(). I think in most cases, splitting NaNs across the start and end of the list isn't desired behavior, so I'll probably keep using partial_cmp with my own handling.
- nixpulvis 4y ago
  Does SQL define a default order/placement for NULLs in numeric (or otherwise) columns?
- tialaramex 4y ago
  I think I'd be happier to see total_cmp anywhere that it's clear we want some consistent order and it's not important what the order actually is. The hand-rolled solution risks inconsistency. Given the opportunity to pick the order, people are going to pick different orders, sometimes by mistake, and providing total_cmp fixes that. I can see that in things which decided they should be Ord but internally have a f32 and so they need to implement the comparison themselves, total_cmp seems like it's almost always going to be the right choice for that unless partial_cmp with unwrap() is definitely correct and they're sure of it.
- jcranmer 4y ago
  This is based on the IEEE 754 totalOrder predicate. If you look at how this function works on binary floats, it turns out that it sorts numbers as 0xffff, 0xfffe, 0xfffd, ..., 0x8001, 0x8000, 0x0000, 0x0001, 0x0002, ..., 0x7ffd, 0x7ffe, 0x7fff [1]. This is not a bad sort order, and the reason why the NaNs are split up are because of the existence of signed NaN. When it comes to floating point, it's probably better to bow to what IEEE 754 specifies (if it specifies something) than do what you come up yourself, even if it's less useful. x != x holding true for NaNs is another example here. [1] Actually, the sort order of NaN payloads is implementation-defined, but given the nice bit representation mentioned above is easy to implement, you're probably unlikely to see any other implementation.
kzrdude 4y ago
And if it's just floats, you can call it like `bois.sort_by(f64::total_cmp)`

From the docstring for total_cmp `bois.sort_by(|a, b| a.weight.total_cmp(&b.weight));` So yes, but you were already able to use `partial_cmp` before.

by Bromeo 4y ago

From the docstring for total_cmp `bois.sort_by(|a, b| a.weight.total_cmp(&b.weight));` So yes, but you were already able to use `partial_cmp` before.

pavon 4y ago

Yeah, the difference is that total_cmp can handle NaNs, whereas with partial_cmp you either had to add your own handling, or get panics on NaN if you blindly call partial_cmp.unwrap(). I think in most cases, splitting NaNs across the start and end of the list isn't desired behavior, so I'll probably keep using partial_cmp with my own handling.

nixpulvis 4y ago
Does SQL define a default order/placement for NULLs in numeric (or otherwise) columns?
tialaramex 4y ago
I think I'd be happier to see total_cmp anywhere that it's clear we want some consistent order and it's not important what the order actually is. The hand-rolled solution risks inconsistency. Given the opportunity to pick the order, people are going to pick different orders, sometimes by mistake, and providing total_cmp fixes that. I can see that in things which decided they should be Ord but internally have a f32 and so they need to implement the comparison themselves, total_cmp seems like it's almost always going to be the right choice for that unless partial_cmp with unwrap() is definitely correct and they're sure of it.
jcranmer 4y ago
This is based on the IEEE 754 totalOrder predicate. If you look at how this function works on binary floats, it turns out that it sorts numbers as 0xffff, 0xfffe, 0xfffd, ..., 0x8001, 0x8000, 0x0000, 0x0001, 0x0002, ..., 0x7ffd, 0x7ffe, 0x7fff [1]. This is not a bad sort order, and the reason why the NaNs are split up are because of the existence of signed NaN. When it comes to floating point, it's probably better to bow to what IEEE 754 specifies (if it specifies something) than do what you come up yourself, even if it's less useful. x != x holding true for NaNs is another example here. [1] Actually, the sort order of NaN payloads is implementation-defined, but given the nice bit representation mentioned above is easy to implement, you're probably unlikely to see any other implementation.

kzrdude 4y ago

And if it's just floats, you can call it like `bois.sort_by(f64::total_cmp)`