-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I actually implemented it that way first. But after long consideration, I decided that a signaling NaN was better. With the non-signaling one, you could go through hours of calculations, only to find that NaN returned at the beginning of them rendered all that work useless.
Of course, the same argument works for quiet NaNs:
I actually implemented it that way first. But after long consideration, I decided that a non-signaling NaN was better. With the signaling one, you could go through hours of calculations, only to find that the NaN returned near the end of them lost all the still-useful work.
Touché. But I still have to disagree. You can prevent signaling NaNs from signaling by testing for them before trying to use them. There are only a tiny number of functions that will return one, after all, and most of those will only do so under specific and user-controlled circumstances. But you can't prevent non-signaling ones from non-signaling. :-)
Why not just support both? One more bit for signalling or quiet isn't a space problem, since it'd only be defined when the current NaN bit is already set. Then in the code you already have to check NaN would look at the bit to decide how to respond.
The problem wouldn't be with space, but with interface -- you'd have to have a way to tell the library which type of NaN to return, from the functions that can normally return one. I can think of several ways around that, but all of them feel... ugly. They would require too many logical inconsistencies and too much special-case coding, both in the library and for users of the library. For example, the best way I can see so far would be to simply allow the not-a-number exception to be blocked. But then what do you return for functions like even() or odd()? getbit()? How should comparisons be handled -- is a NaN greater than or less than any specific number? Neither true nor false is a valid answer, because the question itself is nonsensical. In most cases, throwing an exception is the only response that isn't obviously and horribly wrong.
It would probably mean that the NaN-checking prefix in the functions would end up being a macro instead of an ordinary function call, but I think it'd be worth it.
I'm not sure that it would. There's a concept among theoretical mathematicians, that when an equation feels ugly, it's probably incomplete or incorrect. Similarly, I've found that when a decision leads to an interface that feels ugly, then it's probably the wrong decision.
When deciding to allow NaNs, did you consider allowing infinities as well? That's idle curiosity, though; I don't have a use case in mind.
I don't see any reason to. Infinity is not-a-number (literally), and can be validly represented as such in the few places where it might be needed, like division by zero when exceptions are blocked. - -- Chad Nelson Oak Circle Software, Inc. * * * -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkuu400ACgkQp9x9jeZ9/wQ8jACfckKKdg+Tyj/HXqccfAGLWwfK /S8AnAnQl2ZqFel+BjkjyfkTNEvnvblZ =wBC7 -----END PGP SIGNATURE-----