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

Subject: Re: [boost] New Boost.XInt Library, request preliminary review
From: Jeffrey Hellrung (jhellrung_at_[hidden])
Date: 2010-04-02 14:32:14

Scott McMurray wrote:
> On 2 April 2010 13:43, Chad Nelson <chad.thecomfychair_at_[hidden]> wrote:
[...]
> I think is_nan(Inf) should be false, but is_finite(Inf) should also be false.

Well is_finite(NaN) should be false as well; is_infinity would be a more 
appropriate predicate.

>> it's not something that can be calculated with, generally.
>>
>> [...]
>>
>> If I don't add an infinity value, I could. I'm leaning toward adding one
>> (with sign), but it will act exactly like a NaN except for comparisons.
>>
> 
> Actually, you *can* calculate with infinity.  That's the reason for
> having it separate from NaN, and why it needs a sign.  Any operation
> with NaN gives a NaN, but at least the following for Infs don't give
> NaNs (for any x, y where is_finite(x) && !is_nan(y)):
> 
>     -(Inf) => -Inf
>     -(-Inf) => Inf
>     x + Inf => Inf
>     x - Inf => -Inf
>     x % Inf => x
>     Inf + Inf => Inf
>     -Inf - Inf => -Inf
>     x < Inf => true
>     x > -Inf => true
>     y <= Inf => true
>     y >= -Inf => true
>     x / Inf => 0
>     x / -Inf => 0
>     if (y != 0) y * Inf => sign(y)Inf
>     if (y != 0) y * -Inf => sign(-y)Inf
> 
> But the indeterminate forms do, of course, give NaNs:
> 
>     Inf - Inf => NaN
>     -Inf + Inf => NaN
>     0 * Inf => NaN
>     0 * -Inf => NaN
>     Inf / Inf => NaN
>     Inf / -Inf => NaN
>     Inf % y => NaN
> 
> Hopefully that'll make you lean further :P

Don't forget (assuming a single unsigned 0):

x / 0 => NaN

and I think you'd want Inf to compare equal with itself (unlike NaN, 
which does not compare equal with itself...and doesn't compare unequal 
with itself, either :/ ).

This is of secondary consideration to the core set of algorithms that 
should just throw whenever something bad happens (e.g., division by 0), 
though.

Another topic:  Chad, how natural is it, implementation-wise, to have a 
signed zero?  I'm guessing you have a sign bit, leading naturally to 
either providing both a +0 or a -0, or ensuring after each operation 
that -0 is normalized to +0.  What are the arguments against a signed 
zero?  Is it possible to simply be agnostic to the sign bit when the 
mantissa is 0?

- Jeff