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

Subject: Re: [boost] New Boost.XInt Library, request preliminary review
From: Scott McMurray (me22.ca+boost_at_[hidden])
Date: 2010-03-27 23:29:28

On 27 March 2010 20:56, Chad Nelson <chad.thecomfychair_at_[hidden]> 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.