How to represent the infinite ?

[Tim Peters]

[Huaiyu Zhu]
> Each time we are having this conversation we go around the same
> circle once or twice.  Let's see if we can find a way out.  I would like
> to divide the issue into three (still somewhat arbitrary) sub-issues, and
> see if any one of them can be resolved in easier/simpler/clearer ways:
>
> 1. How much 754 support is provided by the underlying platforms.
> 2. How do such support vary across the platforms.
> 3. What are the Python designers' wishes.

[on platform variations]
> ...
> I think you are talking about sub-issue 2 here.  Is there some
> place we can find out what these variations are, and how severe they are?

Not that I know of, although several projects have tried and given up.  In
addition to hardware, it varies according to all of compiler, specific
compiler release, libraries, specific library releases, and configuration
options specific to all of the preceding.  If and when vendors chose to
support the optional C99 754 gimmicks, then there will be a uniform way to
proceed.  gcc is making some progress in that direction.

> I can certainly contribute "the patch to enable inf and nan in Python" :-)
> (attached), but I'm sure that's not the reason you are against it.

Because it's a crock <0.1 wink>.  Making x**y different than pow(x, y)
sucks, and even worse if it's in ways that can vary across platforms.  It's
also the case that we believe a majority of Python users *want* overflow
exceptions, and are well served by them.  Unless and until there's a
coherent and reasonably x-platform scheme allowing users to enable and
disable specific numeric exceptions at will, we'll favor griping on overflow
(and divide-by-0, and invalid operation) when it doesn't take heroic effort
to do so (we leave * + - and / alone, except for /-by-0, because it's too
hard to check them -- fpectlmodule.c makes heroic efforts in that direction,
but doesn't work on all platforms, or, over time, even on all platforms it
used to work on).

> ...
> I think you are talking about sub-issue 1 here.  Do you actually believe
> that subset-compliance is worse than none?

For a sufficiently broken subset, yes.  "No possibility ever to raise an
exception" is in fact technically conforming to the standard, as the
possibility for trap handlers of any kind are only encouraged ("should", not
"shall").  That's an area where I want something stronger than the std
requires.

> I'd think that would depend on what subset we are talking about.

For example, fine by me if you can't get at directed rounding modes, despite
that they're mandatory.  Others would disagree with that, btw.

> Certainly "can't provide full support" does not imply "avoid as much as
> possible".  There must be some concrete criteria that are omitted here.

The lack of the possibility to enable and disable exceptions on overflow,
divide-by-0, and invalid operation are hangups to me.  Others may include
underflow in that mix.  Others will include sticky status flags, etc.  You
need to hammer this out in the NumPy community first, though.

[Tim]
>> If Python were 100% 754-conforming, Guido and I would still
>> favor enabling exceptions on overflow, divide-by-zero, and invalid
>> operation, by default.  As things are, you've got no choice at all,
>> unless you want such exceptions enabled and are on a platform where
>> the fpectl module happens to work.

> I think you are talking about sub-issue 3 here.  Could you provide a
> rationale in the context of numerical computation?

Sorry, it's a waste of time to do that again.  There are examples on both
sides, and what they show in aggregate is that different apps need different
exceptional-case behavior, and somtimes even across phases within a single
app, not that NonStop Rulz.  There are even cases that can benefit greatly
just from being able to examine the inexact flag.  754 has lots of good
stuff.

> I can offer an example in support of the opposite side.

Of course you can.  If you tried 3x harder, you could give twenty <wink>.

> ...
> How can this be done by vectorized computation if individual elements
> may throw exceptions?

It's amazing how much numeric computation got done on old Cray boxes, which
didn't give you a choice about blowing up on overflow either.  I don't know
that vectorized computations have any relevance to core Python, but if you
really want to know, in your exp(-x**2) example people used vector merge to
replace "too big" values of x before feeding the X vector into the rest of
the computation.  In the case of Python on a 754 box, you can almost
certainly get away with writing it as exp(-x*x) instead -- and it will
likely run faster, too (x**2 calls the platform pow(); x*x is a straight
multiply).

> Certainly you and Guido have the final say on sub-issue 3.  On
> the other two issues, however, I suspect that
>
> 1. Most platforms these days support 754 to a remarkably good degree, far
>    better than that is allowed in today's Python.

The support code required at the C level is platform-specific, and needs a
phalanx of cooperative platform experts to contribute it.  Slash and burn
will not lead to a good and maintainable result.

> 2. Most number crunchers would be more concerned that it works as well as
>    possible on the platforms available to them, rather than  whether it
>    also works on other platforms.

As I said above, that's why the NumPy community has to agree first.  The
overwhelming majority of plain-core Python users are not number crunchers,
and don't know a NaN from an umlaut.  Giving them either 1j or a NaN from
sqrt(-1) is a Bad Idea.  I would often like 1j or a NaN in my own apps --
but I often want the ValueError Python tries to deliver in that case too.

> 3. The variations across major platforms are minor.

I take it you haven't looked at Python's fpectlmodule.c <wink>.