Why `divmod(float('inf'), 1) == (float('nan'), float('nan'))`

Grant Edwards invalid at invalid.invalid
Thu Sep 18 16:33:11 CEST 2014

On 2014-09-18, Steven D'Aprano <steve+comp.lang.python at pearwood.info> wrote:
> Marko Rauhamaa wrote:
>> Maybe IEEE had some specific numeric algorithms in mind when it
>> introduced inf and nan. However, I have a feeling an exception would be
>> a sounder response whenever the arithmetics leaves the solid ground.
> I'm afraid that you're missing the essential point of INF and quiet NANs,
> namely that they *don't* cause an exception. That is their point.

And it is a very important point.  I spent a number of years working
with floating point in process control where the non-signalling
(propogating) behavior of IEEE inf and NaNs was exactly the right

You've got a set of inputs, and a set of outputs each of which depend
on some (but not usually all of the inputs).  When one of the inputs
goes invalid (NaN) or wonky (creating an infinity), it's vitally
important that the computations _all_ got carried out and _all_ of the
outputs got calculated and updated.  Not updating an output was simply
not an option.

Some outputs end up as NaNs or infinities and some are valid, but
_all_ of them get set to the proper value for the given set of inputs.

Using exceptions would have required a whole "shadow" set of
calculations and logic to try to figure out which outputs were still
valid and could be calculated, and which ones were not valid.  It
would have at least tripled the amount of code required -- and it
probably wouldn't have worked right.

Grant Edwards               grant.b.edwards        Yow! My mind is a potato
                                  at               field ...

More information about the Python-list mailing list