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