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

Subject: Re: [boost] New Boost.XInt Library, request preliminary review
From: Chad Nelson (chad.thecomfychair_at_[hidden])
Date: 2010-04-03 22:06:48

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 04/03/2010 09:03 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.

I have to call that cleanup function anyway, to skip past any leading
zeros left over from whatever operation is being done.

>>> 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) ? 

That's essentially the definition of the sign function. But before I
discovered n1692 and its specification of that function, I just had an
is_negative function in there. There may still be code that relies on
the current behavior. Most likely if there is, I'll be able to find it
quickly, but it's something I'll have to keep in mind if I do that.

> 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.

Other than the potential problem mentioned above, there should be no
issues with implementing it -- *if* I stick with the rules I mentioned,
so that every operation that results in a zero gets a positive zero, and
negative zero is only provided when someone explicitly asks for it.

>>> 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

Noted for possible future reference, but as mentioned, I'd rather not
deal with that stuff right now. Once the library is fully functional, I
could add it, if there's any call for it.

> 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...

I don't know off the top of my head either. They could work as written
(once the sign function is modified to check for zero before negative),
or they could get it completely wrong, I'd have to examine the code for
each function to find out.

>> 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.

I thought the whole point of your proposal was to make it easier for
people writing code on top of XInt? If the point is just to save the one
or two clock cycles that are used for flipping the sign, it's hardly
worth the effort.
- -- 
Chad Nelson
Oak Circle Software, Inc.
*
*
*
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAku39DYACgkQp9x9jeZ9/wSFEwCg3ZaMR1SStcmgEHU9Uvb7sw1P
dnoAn2a/55B6O4pYCHW+NCO8lj2oEKr0
=Fedg
-----END PGP SIGNATURE-----