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-29 01:11:10

Chad Nelson wrote:
>>> Which would defeat the primary purpose of the NaN value in the
>>> XInt library, which is to have something to return instead of
>>> throwing an exception when exceptions are blocked. :-)
>> If that's the purpose of your NaN, why limit your set of "special" 
>> values to just { NaN }, when under some circumstances returning some 
>> representation of infinity (or +infinity or -infinity if you make
>> such a distinction) would be more informative?  For example, you can
>> make n/0 for n != 0 result in infinity,
> 
> I could, but why? Who needs to know that n/0 is specifically infinity,
> rather than simply NaN? If you can point out a case where it would help
> someone more than returning a NaN would, I'll be happy to add it.

An xint::integer which is +infinity or -infinity is more meaningful than 
one which is NaN.  At the very least, you can make more refined 
calculations and comparisons with +/-infinity (compared to NaN), 
constructing intervals where either or both endpoints are +/-infinity, etc.

You might feel that an infinity value belongs in a wrapper class around 
xint::integer, and I would tend to agree.  But I would also put the NaN 
representation in this wrapper class as well, along with the entire 
exception blocking framework.  It seems to me to be orthogonal to the 
rest of the interface, and if one never uses blocking exceptions, it 
seems like a waste.

Also, why does invmod always return an NaN on an invalid inverse, and 
not throw a blockable exception?

- Jeff