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:03:19

Chad Nelson wrote:
> On 04/02/2010 09:56 PM, Jeffrey Lee Hellrung, Jr. wrote:
> 
>> You seem to really want some kind of one-to-one identification between
>> integers and xint::integer objects,
> 
> Well, yes -- the xint::integer objects represent integers, after all. ;-)

Yes, and IEEE floats represent (limited precision and limited range) 
dyadic rationals.  My point is, it can be practical and efficient to 
have 2 different underlying representations for the same abstract 
instance.  You're already carrying around a sign bit + mantissa to 
represent an integer, so it seems to me unnatural to bend over backwards 
(exaggeration) to keep that sign bit unset when the mantissa drops to 0, 
if you really don't have to.

>> have yet to see where this makes a difference in the core interface
>> or complicates the internal implementation.
> 
> It would a bit, because there may be code in there that assumes that if
> the negative Boolean is true, the value is less than zero.

Isn't the sign just (mantissa == 0 ? 0 : sign_bit ? -1 : 1) ?  Perhaps I 
should've been clearer:  I have yet to see where this makes the internal 
implementation more complicated than assuming a unique zero 
representation, and it appears like it would simplify implementation as 
you avoid "cleaning up" a -0.  However, the one thing I haven't done is 
actually *look* at the current implementation, and I was hoping your 
familiarity would be able to pinpoint some precise issue.

>> I don't know what you mean here.  Isn't the arithmetic involving zeros
>> fairly straightforward, signed or not?
> 
> If the zeros aren't signed, yes. If they are, and the library is
> supposed to honor the signs, things could get hairy. But it appears that
> I misunderstood your intentions... if a negative zero is still treated
> as zero, then all the math works out.

For reference, wikipedia outlines the arithmetic rules specific to 
signed zeros in their "signed zeros" article:

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

What I would like to happen is, for example, the "natural" 
implementation of addition, where you don't specifically consider the 
rules for adding signed zeros, automatically works anyway for signed 
zeros.  I might have to delve into the code to actually see what would 
happen...

>>> The aforementioned arbitrary-precision floating point package will just
>>> have to handle that itself, maybe by making an extremely small but
>>> non-zero value and calling it negative zero.
>> *That* seems "messy and arbitrary" ;)
> 
> It might be, it would depend on the design goals of the library.

I think the utility of signed zeros in floating point has been proven, 
so "it would be nice" if that was implemented as naturally as possible. 
  I don't necessarily consider this a requirement of the core library, 
but I think it should be seriously considered.

> You've convinced me not to dismiss the idea out of hand. I'm still not
> sure that it's worthwhile, but I'll probably add it, with the
> understanding that any calculations done with it (except a unary minus)
> will come out with a positive-zero result. If someone needs a negative
> zero, they'll have to explicitly request it via the unary minus.

Well, hopefully whatever zero (whether it's +0 or -0) "falls out" of an 
operation will suffice.  I don't think you want to guarantee every 
result equal to either +0 and -0 (save a unary minus) will be fixed to 
+0.  That defeats the whole point of my proposal.

- Jeff