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