On 27 March 2010 20:56, Chad Nelson <chad.thecomfychair@gmail.com> wrote:
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. 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. 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. 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.