New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
cmath test fails on Solaris 10 #47418
Comments
There is on cmath test failure with 64-bit Python 2.6b1 and 3.0b1 on All builds are compiled with Sun's C compiler using the same options ====================================================================== Traceback (most recent call last):
File "Lib/test/test_cmath.py", line 294, in test_cmath_matches_math
self.rAssertAlmostEqual(math.log(v, base), z.real)
File "Lib/test/test_cmath.py", line 128, in rAssertAlmostEqual
self.fail("%s and %s are not sufficiently close" % (repr(a),
repr(b)))
AssertionError: 6.6438561897747244 and 0.71244141339823108 are not
sufficiently close |
Nasty. Here is the test extracted from test/test_cmath.py import math, cmath
test_values = [0.01, 0.1, 0.2, 0.5, 0.9, 0.99]
positive = test_values + [1.] + [1./x for x in test_values]
for base in [0.5, 2., 10.]:
for v in positive:
z = cmath.log(v, base)
x = math.log(v,base)
print(base, v, z, x, z.real-x) On Winxp 3.0b1, |difference| is usually 0.0, else < 2.8e-17 On your system, is cmath64.log totally broken or just for base < 1? |
This one's quite baffling. Jean, can you confirm whether cmath.log(0.01, 0.5) and cmath.log(100., (6.6438561897747244-0j) (the sign on the imaginary part might turn out as + instead of -; that's |
3 different Python 2.6b1 builds:
Python 2.6b1 (r26b1:64398, Jun 19 2008, 20:27:39) [C] on sunos5
Type "help", "copyright", "credits" or "license" for more information.
>>> import cmath
>>> cmath.log(0.01, 0.5)
(0.71244141339823108+2.0556715512777863j)
>>> cmath.log(100.0, 2.0)
(0.71244151439608006-2.0556716794852954j)
Python 2.6b1 (r26b1:64398, Jun 24 2008, 13:50:09) [C] on sunos5
Type "help", "copyright", "credits" or "license" for more information.
>>> import cmath
>>> cmath.log(0.01, 0.5)
(6.6438561897747244-0j)
>>> cmath.log(100.0, 2.0)
(6.6438561897747253+0j)
Python 2.6b1 (r26b1:64398, Jun 23 2008, 18:36:08)
[GCC 4.0.1 (Apple Computer, Inc. build 5367)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import cmath
>>> cmath.log(0.01, 0.5)
(6.6438561897747244-0j)
>>> cmath.log(100.0, 2.0)
(6.6438561897747253+0j) |
More curious and more curious... I assume that cmath.log(100.0) and cmath.log(2.0) return the right things? Might this be some optimization bug? Can you turn off all optimizations |
For 32-bit, see the latest posts at <http://bugs.python.org/issue3167\>. |
What about cmath.log(100.0) and cmath.log(2.0) on 64-bit? |
Here are the 64-bit results. First with -xO5: Python 2.6b1 (r26b1:64398, Jun 28 2008, 10:57:27) [C] on sunos5
Type "help", "copyright", "credits" or "license" for more information.
>>> import cmath
>>> cmath.log(100.0)
(4.6051701859880918+0j)
>>> cmath.log(2.0)
(0.69314718055994529+0j)
>>> cmath.log(100.0, 2.0)
(0.71244151439608006-2.0556716794852954j)
>>> import math
>>> math.log(float('-inf'))
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ValueError: math domain error This is 64-bit with -xO0: Python 2.6b1 (r26b1:64398, Jun 28 2008, 11:02:57) [C] on sunos5
Type "help", "copyright", "credits" or "license" for more information.
>>> import cmath
>>> cmath.log(100.0)
(4.6051701859880918+0j)
>>> cmath.log(2.0)
(0.69314718055994529+0j)
>>> cmath.log(100.0, 2.0)
(6.6438561897747253+0j)
>>> import math
>>> math.log(float('-inf'))
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ValueError: math domain error |
Forgot to mention, both 64-bit builds above includes -xlibmieee in the The complete .configure command line was (with OPT adjusted accordingly): env CCSHARED="-KPIC" LDSHARED="cc -xtarget=native64 -G" LDFLAGS="- |
This looks a lot like a compiler bug, then. Do you agree? I guess the next step would be to try to extract a smallest failing But at this point I'm going to claim that this bug isn't Python's fault, |
This is pretty bizarre, take a look at the following, 64-bit Pyhon 2.6b1 Python 2.6b1 (r26b1:64398, Jun 28 2008, 12:50:06) [C] on sunos5
Type "help", "copyright", "credits" or "license" for more information.
>>> import math
>>> math.log(100.0, 2.0)
6.6438561897747253
>>> math.log(100.0) / math.log(2.0)
6.6438561897747253
>>> import cmath
>>> cmath.log(100.0, 2.0)
(0.71244151439608006-2.0556716794852954j)
>>> cmath.log(complex(100.0, 0), complex(2.0, 0))
(0.71244151439608006-2.0556716794852954j)
>>> cmath.log(2.0)
(0.69314718055994529+0j)
>>> cmath.log(100.0)
(4.6051701859880918+0j)
>>> cmath.log(100.0) / cmath.log(2.0)
(6.6438561897747253+0j) There is only an issue with cmath.log(100.0, 2.0) but not with |
Trying to isolate and duplicate the problem with c_quot isn't quite |
Could you try the attached patch, and see what output you get from |
I'd expect that you'd need both the cmath_log and the c_quot functions, |
I have not yet been able to duplicate the problem in a smaller test
to if (PyTuple_GET_SIZE(args) == 2) {
y = c_log(y);
x = c_quot(x, y);
} fixes the problem for the 64-bit -xO5 Python build. The result is no >>> cmath.log(100, 2)
(6.6438561897747253+0j)
>>> cmath.log(0.01, 0.5)
(6.6438561897747244-0j) |
Attached is a test case which does demonstrate the problem. See the top |
File but showing -xO0 thru -xO5 results. |
Without changing the cmath_log code, another workaround is to compile |
There is another, perhaps related issue on Solaris. The compiler warns Commenting out this line in pyconfig.h as /* #define HAVE_FINITE 1 */ make that warning go away. If there is no function finite, why is |
Below is the reply from SUN. It was indeed a bug which has been fixed already. I have not yet applied the patches to my SUN compilers and tried again. /Jean Begin forwarded message: From: Sun Microsystems <IncidentUpdateDaemon@sun.com> Subject: Re: (Incident Review ID: 1284413) Sun C 5.8 optimization bug for 64-bit Opteron --- Note: you can send us updates about your Incident --- Hi Jean Brouwers, We appreciate your feedback. Using your sample I was able to get the correct results using Sun <http://developers.sun.com/sunstudio/downloads/patches/ss11_patches.html\> Regards, ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --------------- Previous Messages ---------------- --------------------- Report ---------------------
subcategory : compiler FULL PRODUCT VERSION : ADDITIONAL OS VERSION INFORMATION : EXTRA RELEVANT SYSTEM CONFIGURATION : A DESCRIPTION OF THE PROBLEM : typedef struct {
double real;
double imag;
} complex_t; complex_t c_comp(double real); x = c_comp(4.6051701859880918);
y = c_comp(0.69314718055994529);
q = c_quot(x, y);
r = c_quot(x, c_comp(0.6931471805599452));
... STEPS TO FOLLOW TO REPRODUCE THE PROBLEM : EXPECTED VERSUS ACTUAL BEHAVIOR : rm a.out ; cc -xtarget=native64 -xO0 c_main.c c_quot.c -lm ; ./a.out ACTUAL - rm a.out ; cc -xtarget=native64 -xO3 c_main.c c_quot.c -lm ; ./a.out REPRODUCIBILITY : ---------- BEGIN SOURCE ---------- /* Split this file in 3 separate file, c_main.c, c_quot.h and rm a.out ; cc -xtarget=native64 -xO0 c_main.c c_quot.c -lm ; ./a.out rm a.out ; cc -xtarget=native64 -xO1 c_main.c c_quot.c -lm ; ./a.out rm a.out ; cc -xtarget=native64 -xO2 c_main.c c_quot.c -lm ; ./a.out rm a.out ; cc -xtarget=native64 -xO3 c_main.c c_quot.c -lm ; ./a.out rm a.out ; cc -xtarget=native64 -xO4 c_main.c c_quot.c -lm ; ./a.out rm a.out ; cc -xtarget=native64 -xO5 c_main.c c_quot.c -lm ; ./a.out */ ------------------ save as c_main.c ----------------- #include <stdio.h>
#include "c_quot.h"
int main(int argc, char* argv[])
{
complex_t x, y, q, r;
x = c_comp(4.6051701859880918);
y = c_comp(0.69314718055994529);
q = c_quot(x, y);
/* expect: 6.643856 + j 0.000000 */
printf("%f + j %f\n", q.real, q.imag);
x = c_comp(4.6051701859880918);
y = c_comp(0.69314718055994529);
r = c_quot(x, c_comp(0.6931471805599452));
/* expect: 6.643856 + j 0.000000, but ... */
printf("%f + j %f\n", r.real, r.imag);
} ------------------ save as c_quot.h ----------------- typedef struct {
double real;
double imag;
} complex_t; complex_t c_comp(double real); ------------------ save as c_quot.c ----------------- #include "c_quot.h"
complex_t
c_comp(double real)
{
complex_t c;
c.real = real;
c.imag = 0.0; /* ignore imag */
return c;
}
complex_t
c_quot(complex_t a, complex_t b)
{
complex_t r;
r.real = a.real / b.real;
r.imag = 0.0; /* ignore imag */
return r;
} ---------- END SOURCE ---------- CUSTOMER SUBMITTED WORKAROUND : |
Thanks, Jean. I've checked in your workaround in r64735. Leaving this open for now as a reminder about finite/is_finite. |
I don't think this is too serious. My guess would be that both finite and So a code snippet that refers to 'finite' emits a warning, but compiles Could you take a look in the 'config.log' file after configuring and see The right fix is probably to rework things to use 'isfinite' in preference |
Can't find that particular message. Attached is the entire log of one of |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: