The log() function seems to give incorrect results for
large numbers on a 64-bit powerpc architecture. The
test_math program from the Python test suite fails with
the following message:

math module, testing with eps 1e-05
constants
acos
asin
atan
atan2
ceil
cos
cosh
degrees
exp
fabs
floor
fmod
frexp
hypot
ldexp
log
Traceback (most recent call last):
  File "test_math.py", line 117, in ?
    testit('log(10**40, 10)', math.log(10**40, 10), 40)
  File "test_math.py", line 13, in testit
    raise TestFailed, '%s returned %f, expected %f'%\
test.test_support.TestFailed: log(10**40, 10) returned
21.938200, expected 40.000000

Tested on a SMP IBM PowerPC machine, with Python 2.3.4
(64-bit build).

Logged In: YES 
user_id=33168

Can you test with newer versions of Python, preferrably 
2.4.2 or current CVS?  2.3.4 worked for me on 64-bit Opteron.

Logged In: YES 
user_id=298758

I have tried this with python 2.4, 2.4.1, and now 2.4.2. All of 
them face the same problem where log won't work correctly 
on ppc64. The same code works just fine for me on ia32, 
ia64, ppc32, s390, s390x, and x86_64. Only ppc64 sees the 
problem.

The problem can be reproduced easily on a ppc64 system 
with python having been built as a 64-bit binary. Just start 
python in interactive mode and enter the following commands:

   >>import math
   >>math.log(10**40, 10)

The correct answer is 40, but on ppc64 the result comes 
back as 21.938200260161128. I'm not very familiar with the 
python source code, but with a little playing I came up with a 
way to correct the problem. I don't know why the problem 
gets resolved, but it does. By adding a simple printf near the 
end of the loghelper function in Modules/mathmodule.c, the 
problem goes away. Here's a diff showing the change I made 
to get things working correctly:

--- mathmodule.c.SAV    2005-10-03 12:56:38.468014112 -
0500
+++ mathmodule.c        2005-10-03 12:57:35.192044904 -
0500
@@ -224,6 +224,7 @@
                   log(x) + log(2) * e * SHIFT.
                   CAUTION:  e*SHIFT may overflow using int 
arithmetic,
                   so force use of double. */
+               printf("", (e * (double)SHIFT));
                x = func(x) + (e * (double)SHIFT) * func(2.0);
                return PyFloat_FromDouble(x);
        }

Maybe someone who is more familiar with the python code 
can figure out why a change like this would make a difference.

Logged In: YES 
user_id=31435

When you add a print and the problem goes away, the cause 
is almost certainly an optimization bug in the C compiler you 
used to compile the module.

Try compiling mathmodule.c with optimization turned off.  I 
bet that makes the problem go away.  If so, you should 
report the optimization bug to your compiler vendor (you 
didn't say which C compiler you're using, BTW).

Logged In: YES 
user_id=33168

That makes me wonder if it's a compiler issue.  Can you try
building without optimization and see if that fixes your
problem?  What are the compiler flags used?

Logged In: YES 
user_id=298758

I think both you guys are right that this appears to be a 
compiler issue. I am using gcc 3.4.3. The compiler flags 
being used were "-DNDEBUG -g -O3 -Wall -Wstrict-
prototypes". When I redid the build with the -O3 removed 
everything worked fine with log. I'm going to pass this 
problem on to the gcc folks for them to investigate.

Logged In: YES 
user_id=33168

Closing this bug as it seems to be gcc related.  Thanks for
your comments.