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-03-28 17:32:18

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

On 03/28/2010 02:37 PM, Jeffrey Lee Hellrung, Jr. wrote:

>>> (Aside: Division by zero should only produce an infinity if you make a
>>> distinction between +0 and -0.)
>>
>> I can't tell whether you've never realized the logic behind zero and
>> infinities, or whether you're so far beyond me that I just can't
>> follow you.
> 
> Well, neither; just following, again, the IEEE floating point standard:
> 
> 1/+0 = +infinity
> 1/-0 = -infinity
> 
> and also
> 
> 1/+infinity = +0
> 1/-infinity = -0

Those make perfect sense, but only if you assume that +0 and -0
represent numbers that are very close to zero, but not *exactly* zero.
Since this is explicitly an integer library, they aren't needed here.

By the same token, specific infinity values aren't needed either. The
library will represent, exactly, any value that it can access enough
memory for, and will throw an exception on any value with a greater
magnitude than that.

> I guess I implicitly assumed that, if one were to represent "infinity",
> it would be desirable to distinguish between +infinity and -infinity,

Certainly, the two are distinct values with the same magnitude.

> which compels one to further distinguish between +0 and -0.
> I guess you can have a single infinity (and, correspondingly, a
> single 0).

With a single (integer) zero, n / 0 = infinity, and -n / 0 = -infinity.
No specific need for a signed zero value for that.

>> Forgive any mathematical terminology errors, I'm only an armchair
>> mathematician. But in the domain of natural numbers, zero, by
>> definition, has no sign. It's neither positive nor negative (or if you
>> prefer, it's both). Signed zero seems to be an invention of computer
>> science, where it represents a fraction that's so small that the inexact
>> computer representation is indistinguishable from zero, but where the
>> number itself isn't necessarily true zero.
> 
> +/-0 would carry the same meaning they do for IEEE floating point. [...]

An integer library has no need for that meaning. There is only one value
between -1 and +1, and that's exactly zero -- it has no need to
represent infinitely small fractions between zero and the first integral
number in either direction, the way a floating-point library does.

>> The XInt library only represents integers, and unbounded ones, so
>> it follows the mathematical rules of numbers, rather than those of
>> inexact representations. The floating-point library that will
>> inevitably be written on top of XInt, if it's accepted into Boost,
>> will need to deal with that stuff, but XInt itself doesn't.
> 
> That's fine.  Then I don't think it's this library's job to represent
> NaNs, signed zeros and infinities aside.  I guess I dislike the change
> in semantics of NaN from what it is for floating point. 

I'm trying to understand exactly what you're objecting to, but so far
I'm failing. I called that value a Not-a-Number because it represents
the same concept as the floating-point library's Not-a-Number value,
namely something that isn't a valid number. That's the only relationship
the two have to each other.

> NaNs might have a valid use case to simply represent indeterminates,
> but it also might be convenient to guarantee that every xint::integer
> object actually represents an actual integer.  Seems simpler
> (semantics, implementation) to just forego any NaN representation,
> and throw on operations that produce indeterminate, complex, or
> infinite results.

Which would defeat the primary purpose of the NaN value in the XInt
library, which is to have something to return instead of throwing an
exception when exceptions are blocked. :-)
- -- 
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/

iEYEARECAAYFAkuvyt4ACgkQp9x9jeZ9/wSY6wCcDKsV1vCHIMshBSz4wT1+33aH
N6QAoI1/+6RuL+w8BgTxhgjEYVkUkfDj
=6gcG
-----END PGP SIGNATURE-----