Re: [boost] New Boost.XInt Library, request preliminary review

Subject: Re: [boost] New Boost.XInt Library, request preliminary review
From: Jeffrey Lee Hellrung, Jr. (jhellrung_at_[hidden])
Date: 2010-03-28 03:56:29

Chad Nelson 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.
> 
> 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. :-)

Any way this could be a compile-time policy and/or runtime configurable?

> 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.

Can't you return the same result specified by IEEE floating point?  Do 
those operations have standardized results when using NaNs?

>> 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.

(Aside: Division by zero should only produce an infinity if you make a 
distinction between +0 and -0.)

Keep in mind that +/-infinity *is* different than an NaN.  It has a sign 
and a well-defined ordering wrt to "regular" numbers and themselves.

If you are going to represent NaNs, you might as well represent 
+/-infinity and +/-0.  I think the principle of least surprise says to 
follow the semantics of IEEE floating point.  But the best short term 
solution might be to just throw an exception and not worry about NaN's 
or infinities for now.

- Jeff