[infogulch]

So check on construction, when doing operations with other unchecked floats, and when dividing. Any other operations that could produce a NaN?

Wait, are +-Inf considered unordered? Edit: Nope. inf == inf, so you should only have to worry about NaN. https://is.gd/Xi5jdr

[lifthrasiir]

If you want the full list: 0/0, ±inf/±inf, 0 x ±inf, ±inf x 0, inf + (-inf), (-inf) + inf, inf - inf, (-inf) - (-inf). This list is large enough to make NaN checking inefficient.

[infogulch]

Thanks. Yeah maybe not.

It seems like the right way is to add min/max fns to the Iterator trait for PartialOrd that ignore items where partial_ord returns None.

[yorwba]

Not all partial orders have well-defined min/max, though. Ideally, you would want traits for meet/join semi-lattices, but I'm not sure how much abstract algebra you can inflict on the average Rustacean. Then there is the whole problem of NaN is incomparable with everything, so you'd have to use a non-standard definition of semi-lattice to allow for that.

And do you want max(NaN, 0) to be NaN or 0? There is a case to be made for either possibility.

[infogulch]

If I'm writing a game I don't really care if one of many operations accidentally resulted in NaN I would like to treat NaN like SQL treats NULL: pretend it doesn't exist. I can't glean useful information out of it, might as well try to get something from the rest of the data.

Then again according to float semantics, sum of a list containing NaN must be NaN, so it would make sense to extend that principle to min/max.

But the naive implementation of min/max will never output NaN because NaN always compares false. (... unless NaN is the first element. ugly.)

Maybe making it explicit would be best: Make an explicit fn for float collections that filters out NaN in an Iterator, then claim that Item is totally ordered. I'm too much of a rust noob to know if this is possible. (playground here I come!)