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

Subject: Re: [boost] New Boost.XInt Library, request preliminary review
From: OvermindDL1 (overminddl1_at_[hidden])
Date: 2010-04-03 21:54:48

On Sat, Apr 3, 2010 at 7:27 PM, Jeffrey Lee Hellrung, Jr.
<jhellrung_at_[hidden]> wrote:
> 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.

With all of the issues I have seen so far, from signed zeros and
infinities to exception throwing and NaN's, seems it all could be
policy based, would be more work, but it does not all need to be done
at once, just make sure a good, powerful policy framework is ready,
and it can be extended over time, and user code can expand it
themselves to allow for other representations of what they need.  All
modern compilers will easily optimize out all the cruft, so just the
code needs to be written for it.

P.S.  I love the ideas of fixed_xint and so forth, why not expand it
to xint<fixed,infinities> and so forth, with some typedefs for generic
versions?