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-03-28 14:37:36

Chad Nelson wrote:
> 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.

Sure.

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

Sure, informally.

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

Sure.

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

Well, neither; just following, again, the IEEE floating point standard:

1/+0 = +infinity
1/-0 = -infinity

and also

1/+infinity = +0
1/-infinity = -0

I guess I implicitly assumed that, if one were to represent "infinity", 
it would be desirable to distinguish between +infinity and -infinity, 
which compels one to further distinguish between +0 and -0.  I guess you 
can have a single infinity (and, correspondingly, a single 0).

> 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.  They 
behave exactly identically except for a few exceptional operations 
(e.g., when you divide by them).

[...slicing pies...]
> 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.  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.

[...more discussion on +/-0 and +/-infinity...]

- Jeff