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 11:59:42

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

On 03/28/2010 03:56 AM, Jeffrey Lee Hellrung, Jr. wrote:

>> Touché. But I still have to disagree. You can prevent signaling
>> NaNs from signaling by testing for them before trying to use them.
>> There are only a tiny number of functions that will return one,
>> after all, and most of those will only do so under specific and
>> user-controlled circumstances. But you can't prevent non-signaling
>> ones from non-signaling. :-)
> 
> Any way this could be a compile-time policy and/or runtime
> configurable?

Certainly, but I'll need a compelling use-case for it. I'd rather not
spend the time putting such a feature in if no one needs it or is going
to use it.

>> For example, the best way I can see so far would be to simply allow the
>> not-a-number exception to be blocked. But then what do you return for
>> functions like even() or odd()? getbit()? How should comparisons be
>> handled -- is a NaN greater than or less than any specific number?
>> Neither true nor false is a valid answer, because the question itself is
>> nonsensical. In most cases, throwing an exception is the only response
>> that isn't obviously and horribly wrong.
> 
> Can't you return the same result specified by IEEE floating point?  Do
> those operations have standardized results when using NaNs?

In the IEEE system, comparisons involving NaNs always return false.
That's consistent, but not logically correct -- a NaN is not "not less
than" or "not greater than" a number.

I don't think there are any IEEE functions for even or odd (that
requires an exact representation) or getbit (that wouldn't be meaningful
on floating-point numbers), or most of the other problematic XInt functions.

>>> When deciding to allow NaNs, did you consider allowing infinities as
>>> well?  That's idle curiosity, though; I don't have a use case in mind.
>>
>> I don't see any reason to. Infinity is not-a-number (literally), and can
>> be validly represented as such in the few places where it might be
>> needed, like division by zero when exceptions are blocked.
>
> (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.

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.

You can see why dividing a non-zero number by zero produces infinity
with a simple thought experiment. Imagine a pie divided into four
slices, another into three slices, and another into two. Each time you
decrease the number of slices by one, the size of each slice not only
gets larger, but does so at an exponentially-increasing rate. (Again, my
terminology may be off, but that's the basic idea.) By the time you get
to one "slice," you get the whole pie with no cuts at all.

Extending that to fractions (which is physically impossible, but
logically definable), if you cut it into 0.5 "slices," you get two whole
pies. 0.1 slices gives you ten whole pies. 0.01 gives you 100, and it
just keeps going up at the same exponential rate. If you try to reduce
it to *zero* slices, you get an infinite number of pies -- not just a
inexpressably and unimaginably large number, but an *impossible* number.
If the entire universe were pies, it still wouldn't accurately express
the result of dividing a pie by zero.

It occurred to me as I was writing the above that you're probably
approaching the problem from the domain of computer science and
floating-point representations of numbers, rather than pure mathematics.
A floating-point number is an inexact representation of a true number,
so it follows slightly different rules. 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.

> Keep in mind that +/-infinity *is* different than an NaN.  It has a sign
> and a well-defined ordering wrt to "regular" numbers and themselves.

Certainly, in both computer science and mathematics. But by the
mathematical definition, infinity isn't a number, it's a representation
of an impossible number. So logically, representing it with the
not-a-number value is correct.

> If you are going to represent NaNs, you might as well represent
> +/-infinity and +/-0.  I think the principle of least surprise says to
> follow the semantics of IEEE floating point. 

Sorry, but I disagree. XInt is integers, not floating point numbers. It
*would* surprise me if an integer library slavishly followed
floating-point semantics. NaN has a well-defined meaning for integers.
The rest does not.

> But the best short term solution might be to just throw an exception
> and not worry about NaN's or infinities for now.

There we can agree. :-)
- -- 
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/

iEYEARECAAYFAkuvfOoACgkQp9x9jeZ9/wTOewCfTZk/4tE14ShV3E3tUG2QObbQ
UxsAoKitvHNlapzFcKDXbVvXtel3KXSp
=imWc
-----END PGP SIGNATURE-----