Re: [boost] [xint] Boost.XInt formal review

Subject: Re: [boost] [xint] Boost.XInt formal review
From: Chad Nelson (chad.thecomfychair_at_[hidden])
Date: 2011-03-06 08:20:30

On Sun, 6 Mar 2011 06:01:24 -0500
Gordon Woodhull <gordon_at_[hidden]> wrote:

> On Mar 6, 2011, at 5:22 AM, Ivan Sorokin wrote:
>> 
>> After your reply I changes my mind. As I see you had considered all
>> my suggestions long before I posted them. If they really lead to
>> unavoidable performance penalty I think current implementation is a
>> good trade-off.
>> 
>> I vote for inclusion XInt into boost.
>
> Seems like Chad's reply was off-list?    

Not deliberately. I hit reply as usual, and didn't notice that it
wasn't sent to the list like it usually is. Makes me wonder how many
other replies of mine have gotten misaddressed. :-(

> Could the rest of us see what convinced Ivan?

Certainly, here's the entire reply:

> On Sun, 06 Mar 2011 02:10:50 +0300
> Ivan Sorokin <sorokin_at_[hidden]> wrote:
>
>> I believe that arbitrary precision arithmetic library is very
>> useful. But I don't think that in it's current status XInt is
>> appropriate for boost.  
>
> Regardless, thank you for your comments.
>
>> Below is the list of features which I believe should be improved.
>> The list is sorted by importance.
>>
>> 1. Parametrize with container type. [...]  
>
> I actually tested earlier iterations with containers such as vector
> for their storage. The performance numbers were noticeably worse.
>
>> Another option could be wrapping containers into some entity with 
>> interface suitable for integer_t needs.  
>
> I haven't tried that, but it did occur to me as a way to allow the
> range interface that has been requested. Although again, I'd prefer
> not to do something like that until the internals have stabilized
> some.
>
>> One more thought about "secure" option. There are no standard
>> containers with this option. I think either both standard containers
>> and integer_t should have such option or both shouldn't have. This is
>> yet another argument for container parametrization.  
>
> I'm not sure I understand your argument. Are you saying that because
> there are no standard containers with a zero-memory-before-releasing
> option, that the library shouldn't provide one either?
>
>> 2. Signed Zero.
>>
>> I'm sure that long integer arithmetic should behave as close to
>> native integer numbers as possible. Native integer types don't have
>> negative zero. As the documentation mentions, this is done "for use
>> in a planned future unlimited-precision floating point library".
>> Although the only function that behaves differently on negative and
>> positive zero is sign(true), I still believe that this is redundant
>> and planned floating point library should use it's own sign bit.  
>
> This was argued over passionately last year. I was on the
> don't-include-it side, but some very compelling reasons convinced me
> to do so, reluctantly. The clincher was that any implementation of the
> aforementioned floating-point library would be seriously hampered
> without it.
>
>> 3. Alternative representation of negative numbers
>>
>> Currently integer_t supports bit arithmetic, but its result differ
>> from one of native integer types: [...]  
>
> For negative numbers, yes, because sign/magnitude is far more
> efficient than two's complement for most operations in this kind of
> library. (Addition and subtraction are the exceptions.)
>
>> I propose the following solution. Currently integer_t stores the
>> sign bit and value bits (absolute value). Instead of the sign bit
>> let integer_t hold a bit "inverse_value" with the following meaning:
>> [...]  
>
> As an option, there might be some call for that. Using that as the
> default would adversely affect the performance, because many of the
> algorithms -- even basic ones like multiplication and division -- are
> geared toward sign/magnitude, necessitating conversion to it before
> every such operation and back after.
>
>> The implementation of addition and subtraction for this
>> representation is not more complicatedthan for current one. But it
>> allows bit arithmetic to work in the same fashion as it works with
>> native integer types.  
>
> Do you foresee a lot of need for such negative value bit-manipulation
> in a large-integer library?
>
>> 4. About options naming.
>>
>> The option name "threadsafe" is misleading as it implies something
>> about concurrency. Instead it means just disabling copy-on-write.
>> [...]  
>
> Copy-on-write is the only thing that *isn't* completely thread-safe
> about the library. Thread-safety is the important feature;
> copy-on-write is an optimization that affects it.
>
>> xint::nothrow_integer really is "xint::integer or nan". Maybe the
>> name that reflects "integer or nan" representation is better?  
>
> Sorry, but I don't understand. xint::nothrow doesn't throw exceptions;
> that is its reason for existing. The ability to hold a Not-a-Number
> value is a secondary aspect, to give it a value that is never valid,
> as a way to report errors.
>-- 
>Chad Nelson
>Oak Circle Software, Inc.
>*
>*
>*
-- 
Chad Nelson
Oak Circle Software, Inc.
*
*
*