
Boost : 
Subject: Re: [boost] New Boost.XInt Library, request preliminary review
From: Jeffrey Lee Hellrung, Jr. (jhellrung_at_[hidden])
Date: 20100328 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
>>> usercontrolled circumstances. But you can't prevent nonsignaling
>>> ones from nonsignaling. :)
>> Any way this could be a compiletime policy and/or runtime
>> configurable?
>
> Certainly, but I'll need a compelling usecase 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
>>> notanumber 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 floatingpoint 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 notanumber (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
> floatingpoint 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk