Dear Cafe, I kinda understand the [Floating](https://hackage.haskell.org/package/base/docs/GHC-Float.html#t:Floating https://hackage.haskell.org/package/base/docs/GHC-Float.html#t:Floating) class doesn't care about NaN, as not expecting all floating point implementations to have such semantics. But [IEEE Silent NaN](https://en.wikipedia.org/wiki/NaN#Quiet_NaN https://en.wikipedia.org/wiki/NaN#Quiet_NaN) has become a norm today, I think it deserves more than mere [isNaN](https://hackage.haskell.org/package/base/docs/GHC-Float.html#v:isNaN https://hackage.haskell.org/package/base/docs/GHC-Float.html#v:isNaN) in the [RealFloat](https://hackage.haskell.org/package/base/docs/GHC-Float.html#t:RealFloat https://hackage.haskell.org/package/base/docs/GHC-Float.html#t:RealFloat) class. While [Signaling NaN](https://en.wikipedia.org/wiki/NaN#Signaling_NaN https://en.wikipedia.org/wiki/NaN#Signaling_NaN) can be an `Exception` triggering bottom like "divide by zero" is, the silent `NaN` feels like a different kind of bottom, or some thing similar to `Nothing` as in the `Num a => Maybe a` monad? Is Haskell's type system capable of encoding silent NaN as a special kind/type of bottom that handleable? Though I don't think I've gained correct understanding at all, on "bottom"s, I'm interested in what options we have to encode them, especially ergonomics ways to handle them accordingly. Best regards, Compl