Numerics, NaNs, IEEE 754 and C99

Nick Maclaren nmm1 at
Thu Jun 15 10:44:37 CEST 2006

In article <12917f6jp7u90f8 at>,
Grant Edwards <grante at> writes:
|> I assume the "you" in that sentence refers to the IEEE FP
|> standards group.  I just try to follow the standard, but I have
|> found that the behavior required by the IEEE standard is
|> generally what works best for my applications.

Well, it could be, but actually it was a reference to the sentence "This
makes sense since such is the limit of division by a quantity that goes
to zero."

|> I do real-world engineering stuff with measured physical
|> quatities.  There generally is no such thing as "true zero".

It is extremely unusual for even such programs to use ONLY continuous
interval scale quantities, but they might dominate your usage, I agree.
Such application areas are very rare, but do exist.  For example, I can
tell that you don't use statistics in your work, and therefore do not
handle events (including the analysis of failure rates).

|> > I fully agree that infinity arithmetic is fairly well-defined for
|> > most operations, but it most definitely is not in this case.  It should
|> > be reserved for when the operations have overflowed.
|> All I can say is that 1/0 => Inf sure seems to work well for me.

Now, can you explain why 1/0 => -Inf wouldn't work as well?  I.e. why
are ALL of your zeroes, INCLUDING those that arise from subtractions,
are known to be positive?

If you can, then you have a case (and an EXTREMELY unusual application
domain.  If you can't, then I am afraid that your calculations are
unreliable, at best.

The point here is that +infinity is the correct answer when the zero is
known to be a positive infinitesimal, just as -infinity is when it is
known to be a negative one.  NaN is the only numerically respectable
result if the sign is not known, or it might be a true zero.

Nick Maclaren.

More information about the Python-list mailing list