Turn off ZeroDivisionError?

[Mark Dickinson]

On Feb 14, 11:09 pm, John Nagle <na... at animats.com> wrote:
>      You also need to think about how conditionals interact with
> quiet NANs.  Properly, comparisons like ">" have three possibilities:

True.  There was a recent change to Decimal to make comparisons (other
than !=, ==) with NaNs do the "right thing":  that is, raise a Python
exception, unless the Invalid flag is not trapped, in which case they
return False (and also raise the Invalid flag).  I imagine something
similar would make sense for floats.

> True, False, and "raise".  Many implementations don't do that well,
> which means that you lose trichotomy.  "==" has issues; properly,
> "+INF" is not equal to itself.

I don't understand:  why would +INF not be equal to itself?  Having
INF == INF be True seems like something that makes sense both
mathematically and computationally.

>      If you support quiet NANs, you need the predicates like "isnan".

They're on their way!  math.isnan and math.isinf will be in Python
2.6.

> C++ exception using Microsoft's compilers.  But that's not portable.
> x86 has exact exceptions, but most other superscalar machines
> (PowerPC, Alpha, if anybody cares) do not.

Interesting.  What do you mean by 'exact exception'?

>      For Python, I'd suggest throwing a Python exception on all errors
> recognized by the FPU, except maybe underflow.

Yes:  I think this should be the default behaviour, at least.  It was
agreed quite a while ago amongst the Python demigods that the IEEE
overflow, invalid and divide-by-zero signals should ideally raise
Python exceptions, while underflow and inexact should be ignored.  The
problem is that that's not what Python does at the moment, and some
people rely on being able to get NaNs and infinities the old ways.

> If you're doing
> such serious number-crunching that you really want to handle NANs,
> you're probably not writing in Python anyway.

If you're worried about speed, then I agree you probably shouldn't be
writing in Python.  But I can imagine there are use-cases for nonstop
arithmetic with nans and infs where speed isn't the topmost concern.

Mark