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