[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
Zeroes and infinities (and NaNs)
As I mentioned earlier, 754 conflates several concepts into fewer
entities, so that Zero, Inf and NaN are overloaded. There are guiding
principles for the choices that were made, but those are NOT absolute
rules, and the principles are not universally applicable.
The guiding principle for Inf is limits for large finite numbers.
The guiding principle for NaN is deferred error detection, and NOT
indeterminate value (or missing value, or any of the others). This
is why NaNs normally propagate. Exceptions like maxNum() are explicit
(in this case, the closest NaN interpretation may be "missing value").
I am less familiar with the various considerations that went into some
of the rules for signed zeros, but I suspect that the guiding principle
was preservation of certain arithmetic identities, such as 1(1/x) = x.
Clearly, other identities may suffer, e.g. 1/sqrt(x) >= 0 (or NaN).
Perhaps we should collect identities that are expected to be universal,
and mention some of the ones that have exceptions.
Note that the need for exceptions is evident even in pure mathematics.
For example, one might like basic operations to be closed -- but division
requires an exception if other, more important, properties are to be
preserved (e.g. field axioms). FP operations ARE closed, but only by
adding the entities being discussed here (never mind field axioms).
Thorsten also wrote:
[Peter Henderson wrote]
and it allows overflow and divide by zero to be indicated without
having to check flags or causing a core dump.
I am a programmer. I have never ever checked if the result of a
division is +-Infinity. In fact, I always avoid infinities,
division by zero and NaNs like the pest. The reason is easy: You
can't do meaningful calculations with these values.
It all depends on the application. I have written programs for both
IEEE FP and IBM hex (HFP has no infinities and traps on divide-by-zero).
The IEEE version was much simpler, as in my case (slope calculations)
it was a natural fit. One still has to be careful, and one has to think
about the same issues (for example, it matters whether the denominator
is known to be non-negative, and that includes avoiding -0), but the
resulting code is much cleaner (and comments point out why).
Not exactly. FP numbers are exact representations of real numbers. It
is the floating point operations +, -, / and * that are approximations
of their counterparts from the real number system, just as any floating
point evaluation of a function is an approximation of the actual real
value.
No, I didn't mean that FP numbers should model crude approximations of
R and C or model an interval, but that the "crude approximation" is
inherently a result of limited precision. As you say, the FP numbers
should model R and C and therefore its division operator.
Again, the IEEE standard defines the arithmetic precisely to have exact
properties, as well as properties that model inexact arithmetic. The
exact properties are essential for multiple-precision arithmetic for
example, or things like the exact remainder operation. I wish we had
retained the Distill operations that were in the draft two years ago,
but at least we still have the ability to implement them, though not
with proper Inexact indications (except at unreasonable cost).
Now the hardware thing: A trap is nothing else than an interrupt caused
by the FP unit, normally on IRQ channel 13 on the 80x86. The interrupt
handler is called (leaving the current state unchanged), executing code
and returning with IRET.
As *all* hardware is communicating with the processor in this way I would
be very astonished that there would be a remarkable performance penalty.
ALL hardware???? This is incredibly naive. Even within the x86 family
there are, or could be, other ways of implementing traps. The two types
that I'm familiar with, IBM p and IBM z, are totally dissimilar in this
respect, and neither comes even close to the way you describe it.
Michel.
Sent: 2007-06-13 15:34:43 UTC