On 2014-09-18, Steven D'Aprano <steve+comp.lang.pyt...@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
thing.
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 ...
gmail.com
--
https://mail.python.org/mailman/listinfo/python-list
