Yeah it seems the core quirks are strictly incorrect behaviour, but those behaviours are also due to the lack of Ratio having signal values for undefined values. NaN exists in floating point not because they’re hard - it’s because some values are not definable on any number line. Ratio is just fixed point rational arithmetic so can’t avoid values that are not representable as a finite value, so needs to have +/-Infinity, and can’t avoid non-values, so should have NaN.

Lacking those make its basic arithmetic incorrect, so also failing to ensure correct normalization isn’t too surprising :-/

This sounds so broken. I kinda suspect the amount of code that uses Data.Ratio instead of Rational might be negligible across the whole Haskell ecosystem.

Since the root of the problem is that Ratio can become denormalized, this seems more like a bug more than a wat.

Yeah it seems the core quirks are strictly incorrect behaviour, but those behaviours are also due to the lack of Ratio having signal values for undefined values. NaN exists in floating point not because they’re hard - it’s because some values are not definable on any number line. Ratio is just fixed point rational arithmetic so can’t avoid values that are not representable as a finite value, so needs to have +/-Infinity, and can’t avoid non-values, so should have NaN.

Lacking those make its basic arithmetic incorrect, so also failing to ensure correct normalization isn’t too surprising :-/

This sounds so broken. I kinda suspect the amount of code that uses Data.Ratio instead of Rational might be negligible across the whole Haskell ecosystem.

Turns out, numbers are actually pretty hard.