Hacker News new | comments | show | ask | jobs | submit login

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.

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.

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.

I think though you currently just subtract them and test equality to zero, so it is all done by the hardware.

If you try to compare something to bottom (undefined), your program will crash. Try it.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact