[ramon156]

I wonder if "any code that would create a NaN would error" would suffice here. I don't think it makes sense when you actually start to implement it, but I do feel like making a NaN error would be helpful. Why would you want to handle an NaN?

[westurner]

If you don't handle NaN values, and there are NaNs in the real observations made for example with real sensors that sometimes return NaN and outliers, then the sort order there is indeterminate regardless of whether NaN==NaN; the identity function collides because there isn't enough entropy for there to be partial ordering or total ordering if multiple records have the same key value of NaN.

How should an algorithm specify that it should sort by insertion order instead of memory address order if the sort key is NaN for multiple records?

That's the default in SQL Relational Algebra IIRC?

[thomasmg]

> then the sort order there is indeterminate

Well each programming language has a "sort" method that sorts arrays. Should this method throw an exception in case of NaN? I think the NaN rules were the wrong decision. Because of these rules, everywhere there are floating point numbers, the libraries have to have special code for NaN, even if they don't care about NaN. Otherwise there might be ugly bugs, like sorting running into endless loops, data loss, etc. But well, it can't be changed now.

The best description of the decision is probably [1], where Stephen Canon (former member of the IEEE-754 committee if I understand correctly) explains the reasoning.

[1] https://stackoverflow.com/questions/1565164/what-is-the-rati...

[westurner]

Were the procedures for handling Null and Null pointers well defined even for C in 1985 when IEEE-754 was standardized?

There's probably no good way to standardize how to fill when values are null or nan. How else could this be solved without adding special cases for NaN?

In a language with type annotations we indicate whether a type is Optional:

  def sum(a: float|None, b: Optional[float]) -> None|float :

  def sum(a: float|np.nan|None, b: Optional[float|np.nan]) -> None|float|np.nan :

[westurner]

What is a good sort key for Photons and Phonons? What is a good sort key for H2O water molecules?

[thomasmg]

Well floating point operations never throw an exception, which I kind of like, personally. I would rather go in the opposite direction and change integer division by zero to return MAX / MIN / 0.

But NaN could be defined to be smaller or higher than any other value.

Well, there are multiple NaN. And NaN isn't actually the only weirdness; there's also -0, and we have -0 == 0. I think equality for floating point is anyway weird, so then why not just define -0 < 0.

[MyOutfitIsVague]

I mentioned in a sibling comment, there's a crate that does this in a pretty simple and obvious way: https://docs.rs/ordered-float/latest/ordered_float/