Mailing List Archive: Python: Bugs

[issue15477] test_cmath failures on OS X 10.8

Index | Next | Previous | View Threaded

report at bugs

Jul 28, 2012, 3:03 AM

Post #1 of 7 (82 views)
Permalink

[issue15477] test_cmath failures on OS X 10.8

New submission from Ned Deily <nad [at] acm>:

======================================================================
FAIL: testAtanSign (test.test_cmath.CMathTests)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/test/test_cmath.py", line 526, in testAtanSign
self.assertComplexIdentical(cmath.atan(z), z)
File "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/test/test_cmath.py", line 96, in assertComplexIdentical
self.assertFloatIdentical(x.imag, y.imag)
File "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/test/test_cmath.py", line 86, in assertFloatIdentical
self.fail(msg.format(x, y))
AssertionError: floats -0.0 and 0.0 are not identical: zeros have different signs

======================================================================
FAIL: testAtanhSign (test.test_cmath.CMathTests)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/test/test_cmath.py", line 533, in testAtanhSign
self.assertComplexIdentical(cmath.atanh(z), z)
File "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/test/test_cmath.py", line 95, in assertComplexIdentical
self.assertFloatIdentical(x.real, y.real)
File "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/test/test_cmath.py", line 86, in assertFloatIdentical
self.fail(msg.format(x, y))
AssertionError: floats 0.0 and -0.0 are not identical: zeros have different signs

======================================================================
FAIL: test_specific_values (test.test_cmath.CMathTests)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/test/test_cmath.py", line 382, in test_specific_values
msg=error_message)
File "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/test/test_cmath.py", line 128, in rAssertAlmostEqual
'got {!r}'.format(a, b))
AssertionError: atan1000: atan(complex(-0.0, 0.0))
Expected: complex(-0.0, 0.0)
Received: complex(-0.0, -0.0)
Received value insufficiently close to expected value.

----------------------------------------------------------------------

Failures seen across various compilers and deployment targets and running the tests with the same binaries on earlier OS X versions do not fail.

FWIW, the Apple-supplied Python 2.7.2 in 10.8 (that's the most recent version supplied) also has a test_cmath failure:

======================================================================
FAIL: test_specific_values (test.test_cmath.CMathTests)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/test/test_cmath.py", line 352, in test_specific_values
msg=error_message)
File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/test/test_cmath.py", line 94, in rAssertAlmostEqual
'got {!r}'.format(a, b))
AssertionError: atan0000: atan(complex(0.0, 0.0))
Expected: complex(0.0, 0.0)
Received: complex(0.0, -0.0)
Received value insufficiently close to expected value.

----------------------------------------------------------------------

Is there any reason to not consider this a platform bug? If it is, what should the bug report be?

----------
messages: 166642
nosy: mark.dickinson, ned.deily
priority: normal
severity: normal
status: open
title: test_cmath failures on OS X 10.8
versions: Python 3.3

_______________________________________
Python tracker <report [at] bugs>
<http://bugs.python.org/issue15477>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com

report at bugs

Jul 28, 2012, 4:49 AM

Post #2 of 7 (77 views)
Permalink

[issue15477] test_cmath failures on OS X 10.8 [In reply to]

Mark Dickinson <dickinsm [at] gmail> added the comment:

Judging by previous reports of this type, it's probably either a bug in the platform math library or a compiler optimization bug (or possibly a combination of the two: one previous OS X bug involved calls to sin / cos being 'optimized' to a badly implemented single call to cexp). I assume the failure still happens in debug mode? If so, a math library bug seems more likely.

Are there any math module failures?

It's not immediately obvious what the bug is, since the cmath module functions are not just simple wrappers around library functions. In this case it looks like either atan2 or log1p is doing the wrong thing with signs of zeros.

What do math.log1p(0.0) and math.log1p(-0.0) give? (Answers *should* be 0.0 and -0.0 respectively.)

----------

_______________________________________
Python tracker <report [at] bugs>
<http://bugs.python.org/issue15477>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com

report at bugs

Jul 28, 2012, 4:51 AM

Post #3 of 7 (70 views)
Permalink

[issue15477] test_cmath failures on OS X 10.8 [In reply to]

Mark Dickinson <dickinsm [at] gmail> added the comment:

Also: what's HAVE_LOG1P for this build?

----------

_______________________________________
Python tracker <report [at] bugs>
<http://bugs.python.org/issue15477>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com

report at bugs

Jul 28, 2012, 2:01 PM

Post #4 of 7 (69 views)
Permalink

[issue15477] test_cmath failures on OS X 10.8 [In reply to]

Ned Deily added the comment:

> I assume the failure still happens in debug mode?

Yes

> Are there any math module failures?

No

> What do math.log1p(0.0) and math.log1p(-0.0) give? (Answers *should* be 0.0 and -0.0 respectively.)

>>> math.log1p(0.0)
0.0
>>> math.log1p(-0.0)
0.0
>>> sysconfig.get_config_var('HAVE_LOG1P')
1

----------

_______________________________________
Python tracker <report [at] bugs>
<http://bugs.python.org/issue15477>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com

report at bugs

Jul 28, 2012, 3:17 PM

Post #5 of 7 (69 views)
Permalink

[issue15477] test_cmath failures on OS X 10.8 [In reply to]

Mark Dickinson added the comment:

>>> math.log1p(0.0)
0.0
>>> math.log1p(-0.0)
0.0

Ah, that would do it, then. It looks as though the system's log1p function is buggy, in the sense that it doesn't follow C99 Annex F (F.9.3.9). It also doesn't agree with what 'man log1p' says on my OS X 10.6 Macbook: under 'SPECIAL VALUES', it says: 'log1p(+-0) returns +-0.'

I'm puzzled about one thing, though: there's a test for this problem in the configure script, and LOG1P_DROPS_ZERO_SIGN should be defined in this case---in that case, the two testAtanSign and testAtanhSign tests are skipped. So it looks as though LOG1P_DROPS_ZERO_SIGN isn't being defined on this machine; I'm not sure why---there may be a compiler optimization kicking in in the configure test. (Is this clang or gcc, BTW?)

So definitely worth a bug report, I'd say, though perhaps it's too much to hope for a fix within the lifetime of 10.8.

----------

_______________________________________
Python tracker <report [at] bugs>
<http://bugs.python.org/issue15477>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com

report at bugs

Jul 28, 2012, 4:18 PM

Post #6 of 7 (72 views)
Permalink

[issue15477] test_cmath failures on OS X 10.8 [In reply to]

Ned Deily added the comment:

>>It also doesn't agree with what 'man log1p' says on my OS X 10.6
>>Macbook: under 'SPECIAL VALUES', it says: 'log1p(+-0) returns +-0.'

That manpage is unchanged for 10.8.

>>I'm puzzled about one thing, though: there's a test for this problem
>>in the configure script, and LOG1P_DROPS_ZERO_SIGN should be defined in
>>this case---in that case, the two testAtanSign and testAtanhSign tests
>>are skipped. So it looks as though LOG1P_DROPS_ZERO_SIGN isn't being
>>defined on this machine; I'm not sure why---there may be a compiler
>>optimization kicking in in the configure test.

Ah, this rings a bell and points out yet another issue:

1. The configure test is working properly: when run on 10.8, LOG1P_DROPS_ZERO_SIGN is set to 1. However, something I just ran into recently, the unittest skip idiom using sysconfig.get_config_vars results - as is being used here in test_cmath - doesn't seem to work properly. I see it is used in test_math and test_subprocess as well. I'll look into that.

2. These types of run-time tests based on configure-time tests are problematic for binary installations of Python, like the OS X installers. For example, the OS X installers are built on earlier versions of OS X where a configuration test (like this one) may have one result but not necessarily the same result on all supported target configurations where the binary Pythons may be installed. And, in general, multiple-architecture builds, in particular, OS X universal builds may have different configuration values per architecture embedded in one executable (i386 vs x86_64 or i386 vs ppc or i386 vs x86_64 vs ppc) that are not reflected in the single architecture ./configure results. I guess it's time to open an issue on that can of worms.

>>(Is this clang or gcc, BTW?)

It's clang which is now the only supported option with Xcode 4.4 on either 10.7 or 10.8. More importantly, 10.8 is the first OS X release which itself was built with clang; 10.7 was built with the transitional llvm-gcc compiler.

----------

_______________________________________
Python tracker <report [at] bugs>
<http://bugs.python.org/issue15477>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com

report at bugs

Jul 29, 2012, 2:04 AM

Post #7 of 7 (73 views)
Permalink

[issue15477] test_cmath failures on OS X 10.8 [In reply to]

Mark Dickinson added the comment:

> These types of run-time tests based on configure-time tests are problematic
> for binary installations of Python, like the OS X installers.

Understood. I'm wondering how to fix this for Python, given that we're unlikely to see an OS-level fix for a while. There's an easy workaround, namely to add an "if (x == 0.0) return x;" before any use of the system log1p; the issue is how and when to apply this workaround.

One option is always to apply the workaround, but this feels to me as though it's unnecessarily penalising those OSs that get it right; maybe just always apply the workaround on OS X?

----------

_______________________________________
Python tracker <report [at] bugs>
<http://bugs.python.org/issue15477>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads