Re:NaNs Just Don't Get No Respect
by Evbn on Saturday August 18, 2012 @01:18AM
(#4400316)
Would you prefer NaN be another type, like Maybe? And have to all math in a monad or with chronically repeated case analysis?It's necessary complexity, whichever way you do it.
[ Parent
| on HN ]
Oh, I don't really have a good solution in mind--it's just annoying.
I guess one option would be to just declare that all NaNs are equal--I'm pretty sure that's how bottoms work in Haskell, and it seems that NaN is essentially a floating-point version of bottom.
Re:NaNs Just Don't Get No Respect
by justincormack on Saturday August 18, 2012 @04:33AM
(#4400600)
There are however multiple bit patterns for NaN which complicates that.
Yes. I was actually thinking about this. However, you have a similar problem with the current model: two NaNs can have the same bit pattern, but still have to be unequal.
This is somewhat simpler--as long as either argument to (==) is NaN the answer is False. However, you still have to figure out that at least one bit pattern corresponds to NaN. If you want them to be equal, you would have to figure out that both are NaN. This is certainly a little more difficult, but I think it isn't much worse than the current scenario.
Re:NaNs Just Don't Get No Respect
by justincormack on Saturday August 18, 2012 @06:57AM
(#4400799)
I think though you currently just subtract them and test equality to zero, so it is all done by the hardware.