[Numpy-discussion] RE: Python 2.2 seriously crippled for numerical computation?

[Tim Peters]

[Huaiyu Zhu]
> ...
> 1. The -lieee is indeed the most direct cure.

On the specific platform tried.  The libm errno rules changed between C89
and C99, and I'm afraid there's no errno behavior Python can rely on
anymore.  So I expect more changes will be needed in Python, regardless of
how things turn out on this specific platform.

> ...
> 2. Is there a configure option to guarantee -lieee?

If anyone can answer this question, please don't answer it here:  it will
just get lost.  Attach it to Huaiyu's bug report instead:

 <http://sf.net/tracker/?func=detail&aid=525705&group_id=5470&atid=105470>

Thanks.

> ...
> 3. errno 34 (or -lieee) may not be the sole reason.
>
>    On a RedHat 6.1 upgraded to 7.1 (both gcc and glibc), errno 34
>    is indeed raised in a C program linked without -lieee, and Python is
>    indeed compiled without -lieee, but Python does not raise
>    OverflowError.

I expect you're missing something.  Skip posted the Python code before, and
if errno gets set, Python *does* raise OverflowError:

	errno = 0;  /* Skip forgot to post this line, and it's important */
	...
	ix = pow(iv, iw);
	...
	if (errno != 0) {
		/* XXX could it be another type of error? */
		PyErr_SetFromErrno(PyExc_OverflowError);
		return NULL;

If you can read C, believe your eyes <wink>.

What you may be missing is what an utter mess C is here.  How libm behaves
may depend on compiler options, linker options, global system flags, and
even options set for other libraries you link with.

> ...
> 4. Is there an easier way to debug such problems?

The cause was obvious to the first person (Skip) who stepped into Python to
see what the code did on a platform where it failed.  It's not going to be
obvious to someone who doesn't.

> 5. How is 1e200**2 handled?

It goes through exactly the same code.

>    Since both 1e-200**2 and 1e200**2 produce the same errno all the time,
>    but Python still raises OverflowError for 1e200**2 when linked with
>    -lieee, there must be a separate mechanism at work.

You're speculating from a false base:  if platform pow(x, y) sets errno to
any non-zero value, Python x**y raises OverflowError.  What differs is when
platform pow(x, y) does not set errno.  In that case, Python synthesizes
errno=ERANGE if the pow() result equals +- platform HUGE_VAL.

>  What is that and how can I override it?

Sorry, you can't override it.

>    I know this is by design, but I think the design is dumb (to put it
>    politely). I won't get into an argument here.  I'll write
>    up my rationale against this when I have some time.

I'm afraid a rationale won't do any good.  I'm in favor of supplying full
754 compatibility myself, but:

A) Getting from here to there requires volunteers to design, implement,
   document, and test the code.  Given the atrocious state of C's 754
   story, and the subtlety of 754's requirements, this needs volunteers
   who are both 754 experts and platform C experts.  That combination is
   rare.

B) Python's floating-point users will never agree it's a good thing, so
   such a change requires careful backward compatibility work too.  This
   isn't likely to get done by someone who characterizes the other side
   as "dumb (to put it politely)" <0.9 wink>.

Note that the only significant floating-point code ever contributed to the
Python core was the fpectl module, and its purpose is to *break* 754
"non-stop" exception semantics in the places Python happens to let them
sneak through.

> I do remember there being several discussions in the past, but I don't
> remember any convincing argument for the current decision.  Any URL
> would be greatly appreciated, beside the one pointed by Tim.

Which "current decision" do you have in mind?  There is no design doc for
Python's numerics, if that's what you're looking for.  As the text at the
URL I gave you said, much of Python's fp behavior is accidental, inherited
from platform C quirks.