[Numpy-discussion] RE: Python 2.2 seriously crippled for numerical computation?
Huaiyu Zhu
huaiyu at gauss.almadan.ibm.com
Tue Mar 5 14:09:26 EST 2002
On 04 Mar 2002 15:44:19 -0800, Paul Rubin <phr-n2002a at nightsong.com> wrote:
>huaiyu at gauss.almadan.ibm.com (Huaiyu Zhu) writes:
>> So my question now is: What do I do to tell Python to compile with -lieee?
>
>I just edited the makefile and found the LIBS line and added -lieee.
>I didn't uncomment that #define that you found.
OK, this solves the immediate problem. But there are quite a few puzzles:
1. The -lieee is indeed the most direct cure.
On prestine source, do configure; make; mv python python.bak; make -n
python. This shows the final linking command, which has no -lieee. Use
that line plus -lieee to produce a new python binary. Testing both with
1e-200**2. One raises OverflowError while the other does not.
2. Is there a configure option to guarantee -lieee?
Changing pyconfig.h.in to #define HAVE_LIBIEEE 1 does not make -lieee
appear in the Makefile, even though it get into pyconfig.h.
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.
It appears that the problem is neither gcc nor glibc, as Konrad Hinsen
reported that on a stock RedHat 7.1 Python did raise.
4. Is there an easier way to debug such problems?
Maybe a C test program should be included in the configure script or in
the Tools directory so that people can easily report various conditions?
Such environmental testing is essential if Python is defining its own
numerical behavior indenpendent of IEEE or C. (but see below)
I once asked a question about a wierd behavior of Octave and the author
sent me a C program and asked for results. He modified the program and
asked me to test it again. The problem was solved in just two rounds of
exchange.
5. How is 1e200**2 handled?
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. What is that and how
can I 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 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. Achieving uniformity across
platform alone is not a convincing reason at all - you could let all
computation return zero all the time to achieve the greatest
uniformity. :-)
I hope the above provides enough details and independence among the issues
for experts to ponder about.
Huaiyu
More information about the Python-list
mailing list