[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