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

Subject: Re: [boost] New Boost.XInt Library, request preliminary review
From: Chad Nelson (chad.thecomfychair_at_[hidden])
Date: 2010-03-28 01:04:16

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