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-02 20:57:26

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

On 04/02/2010 03:43 PM, Jeffrey Lee Hellrung, Jr. wrote:

>>> Don't forget (assuming a single unsigned 0):
>>>
>>> x / 0 => NaN
>>
>> Eh? I thought we'd decided that anything divided by zero, other than
>> zero itself, was infinity (or negative infinity, if x is negative)?
> 
> Of course you can define whatever arithmetic you like, but I think it
> makes more sense for products and quotients of like signs being
> positive, of opposite signs being negative, and anything involving
> (unsigned) zero giving either (unsigned) zero or NaN.

You've completely lost me. Zero doesn't have a sign, so anything divided
by zero would have to take its sign from 'x'.

>>> What are the arguments against a signed zero? 
>>
>> That there's no need for it in an integer library.
> [...]
>> As such, there's no real need for it in XInt.
> 
> I was looking more for objections based purely on logical 
> inconsistencies. Can you think of any?

Several. To begin with, would there be different values for positive
zero, negative zero, and "true" zero? If not, zero would have to be
assumed to be positive zero, and that's a slight logical inconsistency
right there.

And if all two or three zero types evaluated the same, how would you
detect a positive zero or a negative zero? The sign() function wouldn't
do it; it's spec'd to return zero for zeros, and it would break a lot of
things in the code if that were changed. Comparison functions would see
them as the same too. You'd have to add a special function just to
detect the sign on a zero.

To make a sensible signed-zero value work, I'd have to make up portions
of the math, or adopt them from floating-point stuff even though that
doesn't make sense here. It gets very messy and arbitrary, and I'd
rather avoid it.

>>> Is it possible to simply be agnostic to the sign bit when the
>>> mantissa is 0?
>>
>> Isn't that the same as saying that -0 is identical to +0?
> 
> If you don't have any infinities or NaNs to worry about, yes!  For this
> case, I'm just suggesting you may not have to normalize zeros if -0
> behaves exactly the same as +0.  But it still may be useful to
> distinguish between them for libraries built on top of the core
> implementation.  An arbitrary-precision floating point type may make a
> distinction between +0 and -0, and it would be convenient if the
> underlying integer core allowed this distinction naturally. [...]

That's about the only argument that had any chance of swaying me. :-)

> What do you think?

That I still don't see any way to cleanly and logically implement it.
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.
- -- 
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/

iEYEARECAAYFAku2knYACgkQp9x9jeZ9/wRpYgCfU7212WL2DPOBjqYVZfieb408
+eUAnjs9uxudwZEBHeufFwfNn7qxN5xD
=hHEW
-----END PGP SIGNATURE-----