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-04-03 21:27:12

Chad Nelson wrote:
> On 04/03/2010 06:11 AM, DE wrote:
[...]
>> assumption: it'll be convenient if a thing, upon which some another
>> thing would be built, provide natively some features which would be
>> useful only in the implementation of that other thing built on top
>> of it
>>
>> this looks like some kind of an inversion or degeneralization
>> sure the prime thing shoud provied complete set of functionality with
>> wich any other extension can be built
>> but since the prime thing is not generally aware of other things which
>> could be built around it it should not provide any feature which would
>> *possibly* be useful
> 
> In general, I agree. But if XInt is accepted into Boost, there will
> *definitely* be an arbitrary-precision real type built onto it. I may do
> it myself, if no one else steps up, but I'm fairly certain that someone
> will -- it's a perfect GSoC project, for example. As such, planning for
> it isn't really degeneralization in this particular case.

Chad gave the practical reason.  But perhaps more fundamentally, the 
information (the sign bit) is *there*, and I'd like it to be usable, 
even if the mantissa is zero.  If you don't want to distinguish between 
-0 and +0 (and I don't see why you would when strictly in the domain of 
integers), then you won't ever notice there are 2 different representations.

>> assumption: there should be signed zeros like that of ieee floating
>> point numbers
[...]
>> that's why you have no sound argument for this -- because it's not
>> natural for ints
> 
> Exactly my thoughts. But if it does make life noticeably easier for
> whoever implements the real type, and doesn't cause any problems with
> the integer type, I'm willing to entertain the idea.

And it *is* natural for sign + magnitude (which I had been slightly 
mistakenly calling "sign + mantissa") representations.  If builtin 
integers were based on a sign + magnitude or 1's complement 
representation, we'd already be used to dealing with signed zeros:

http://en.wikipedia.org/wiki/Signed_number_representations

I'm guessing it's simpler in hardware to use 2's complement, but we're 
pretty much stuck with sign + magnitude AFAICT for an unbounded integer 
library.

>> assumption: the presence of (signed) infinities would provide ultimate
>> set of relationships of the domain entities as well as consistence of
>> some operations' behavior
>>
>> since there was no example of an application of infinities except
>> interval arithmetics i see no reason to provide it [...]
> 
> The more I think about it, the less decided I am over it. I believe
> there are a few cases where it would be useful to have infinities, at
> least for comparisons, but I can't think of any concrete examples and no
> one else has provided any. And it does make for more work, both for me
> in writing it, and (slightly) for the computer when using it.
> 
> At the moment, I'm inclined to leave it out of the library for now, at
> least until someone can show an application where it would be more
> useful than the Not-a-Number value. But there's still at least a few
> days for people to make their cases before I have to make a decision.
> And we can always revisit the idea after the 1.0 release is stable.

True, infinities would have somewhat specialized applications, but it 
makes some sense (to me) to include it if you're already going to waste 
a byte on an NaN flag anyway.

- Jeff