Numerics, NaNs, IEEE 754 and C99
nmm1 at cus.cam.ac.uk
Thu Jun 15 10:44:37 CEST 2006
In article <12917f6jp7u90f8 at corp.supernews.com>,
Grant Edwards <grante at visi.com> 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
|> 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.
More information about the Python-list