This issue tracker has been migrated to GitHub ,
and is currently read-only.
For more information,
see the GitHub FAQs in the Python's Developer Guide.
Created on 2010年09月22日 14:13 by sable, last changed 2022年04月11日 14:57 by admin. This issue is now closed.
| Files | ||||
|---|---|---|---|---|
| File name | Uploaded | Description | Edit | |
| issue9920.patch | mark.dickinson, 2011年02月11日 15:45 | review | ||
| Messages (13) | |||
|---|---|---|---|
| msg117141 - (view) | Author: Sébastien Sablé (sable) | Date: 2010年09月22日 14:13 | |
test_cmath will fail with the following error on AIX: ====================================================================== FAIL: test_specific_values (test.test_cmath.CMathTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/san_cis/home/cis/buildbot/buildbot-aix6/py3k-aix6-xlc/build/Lib/test/test_cmath.py", line 350, in test_specific_values msg=error_message) File "/san_cis/home/cis/buildbot/buildbot-aix6/py3k-aix6-xlc/build/Lib/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. There is a test concerning tanh in configure, which may be related: checking whether tanh preserves the sign of zero... yes |
|||
| msg117142 - (view) | Author: Mark Dickinson (mark.dickinson) * (Python committer) | Date: 2010年09月22日 14:19 | |
Thanks for the report. This looks like it's probably a bug (not a particularly serious one, but worth reporting) on AIX. The 'tanh' configure test diagnoses a similar wrong-sign-of-zero problem on FreeBSD; it looks as though AIX is happy here---that is, 'yes' is the expected and desired result for that configure test. |
|||
| msg117143 - (view) | Author: Mark Dickinson (mark.dickinson) * (Python committer) | Date: 2010年09月22日 14:21 | |
P.S. Was the test with a debug build of Python? If not, could you see if the test failure still occurs with a debug build (i.e., when --with-pydebug is passed as a configure argument)? That would help eliminate compiler optimization bugs as a possible cause. |
|||
| msg117144 - (view) | Author: Mark Dickinson (mark.dickinson) * (Python committer) | Date: 2010年09月22日 14:30 | |
Sorry---one more question: could you tell me what the following gives on the AIX machine? Python 2.7 (r27:82500, Aug 15 2010, 14:21:15) [GCC 4.2.1 (Apple Inc. build 5664)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> from cmath import tanh >>> tanh(complex(-0.0, 0.0)) (-0+0j) Thanks. |
|||
| msg117174 - (view) | Author: Sébastien Sablé (sable) | Date: 2010年09月23日 09:15 | |
Thanks for the quick reply Mark. I tried with pydebug and got the same error. Here is the trace for your last question: Python 3.2a2+ (py3k:84969M, Sep 23 2010, 10:55:24) [C] on aix6 Type "help", "copyright", "credits" or "license" for more information. >>> from cmath import tanh [52276 refs] >>> tanh(complex(-0.0, 0.0)) (-0+0j) [52281 refs] |
|||
| msg117179 - (view) | Author: Mark Dickinson (mark.dickinson) * (Python committer) | Date: 2010年09月23日 10:36 | |
Thanks; so it's probably not an optimization bug, but rather a math library bug somewhere. And thanks for the tanh result; unfortunately I asked the wrong question---I meant to ask about atanh(complex(-0.0, 0.0)) :( Analysis: atan(z) is computed internally as atanh(iz) / i. So if the imaginary part of atan is coming out wrong, it's probably because the real part of atanh is incorrect. So I'd expect atanh(complex(-0.0, 0.0)) to produce 0.0j (instead of the correct answer of -0.0 + 0.0j). The real part of atanh(x + iy) is computed (for a region of the complex plane containing 0.0) using the formula: real_part = log1p(4.*z.real/((1-z.real)*(1-z.real) + z.imag * z.imag))/4.; My best guess is that the log1p function is dropping the sign on a negative zero. But in that case I'd expect test_math to fail on your system, too. Could you try the following experiments, and let me know what you get? (Feel free to stop as soon as your results start to differ from what's below.) >>> import math, cmath >>> math.log1p(-0.0) -0.0 >>> z = complex(-0.0, 0.0) >>> 4. * z.real -0.0 >>> (1 - z.real) * (1 - z.real) + z.imag * z.imag 1.0 >>> 4. * z.real / ((1 - z.real) * (1 - z.real) + z.imag * z.imag) -0.0 >>> math.log1p(4. * z.real / ((1 - z.real) * (1 - z.real) + z.imag * z.imag)) -0.0 >>> math.log1p(4. * z.real / ((1 - z.real) * (1 - z.real) + z.imag * z.imag)) / 4. -0.0 >>> cmath.atanh(z).real -0.0 |
|||
| msg117182 - (view) | Author: Sébastien Sablé (sable) | Date: 2010年09月23日 13:15 | |
No problem; I tried with a different compiler this time (gcc instead of xlc) and with -O0 just to be sure it is not a compiler issue. I had the same error. I tried your test and you are right, the problem happens with log1p dropping the sign: >>> import math, cmath [52601 refs] >>> math.log1p(-0.0) 0.0 I also tried test_math but it seems to work fine: > ./python -E ./Lib/test/test_math.py testAcos (__main__.MathTests) ... ok testAcosh (__main__.MathTests) ... ok testAsin (__main__.MathTests) ... ok testAsinh (__main__.MathTests) ... ok testAtan (__main__.MathTests) ... ok testAtan2 (__main__.MathTests) ... ok testAtanh (__main__.MathTests) ... ok testCeil (__main__.MathTests) ... ok testConstants (__main__.MathTests) ... ok testCopysign (__main__.MathTests) ... ok testCos (__main__.MathTests) ... ok testCosh (__main__.MathTests) ... ok testDegrees (__main__.MathTests) ... ok testExp (__main__.MathTests) ... ok testFabs (__main__.MathTests) ... ok testFactorial (__main__.MathTests) ... ok testFloor (__main__.MathTests) ... ok testFmod (__main__.MathTests) ... ok testFrexp (__main__.MathTests) ... ok testFsum (__main__.MathTests) ... ok testHypot (__main__.MathTests) ... ok testIsfinite (__main__.MathTests) ... ok testIsinf (__main__.MathTests) ... ok testIsnan (__main__.MathTests) ... ok testLdexp (__main__.MathTests) ... ok testLog (__main__.MathTests) ... ok testLog10 (__main__.MathTests) ... ok testLog1p (__main__.MathTests) ... ok testModf (__main__.MathTests) ... ok testPow (__main__.MathTests) ... ok testRadians (__main__.MathTests) ... ok testSin (__main__.MathTests) ... ok testSinh (__main__.MathTests) ... ok testSqrt (__main__.MathTests) ... ok testTan (__main__.MathTests) ... ok testTanh (__main__.MathTests) ... ok test_exceptions (__main__.MathTests) ... ok test_mtestfile (__main__.MathTests) ... ok test_testfile (__main__.MathTests) ... ok test_trunc (__main__.MathTests) ... ok ./Lib/test/ieee754.txt Doctest: ieee754.txt ... ok ---------------------------------------------------------------------- Ran 41 tests in 10.467s OK |
|||
| msg121609 - (view) | Author: Mark Dickinson (mark.dickinson) * (Python committer) | Date: 2010年11月20日 11:09 | |
This should now be fixed in r86553. If you have a chance to test and report back, that would be great! |
|||
| msg128287 - (view) | Author: Sébastien Sablé (sable) | Date: 2011年02月10日 12:37 | |
Mark, sorry for the late reply; I stopped focusing on AIX for some time. I ran test_cmath on trunk this morning and got a different error this time: ====================================================================== FAIL: test_specific_values (test.test_cmath.CMathTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/san_cis/home/cis/.buildbot/python-aix6/py3k-aix6-xlc/build/Lib/test/test_cmath.py", line 382, in test_specific_values msg=error_message) File "/san_cis/home/cis/.buildbot/python-aix6/py3k-aix6-xlc/build/Lib/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. ---------------------------------------------------------------------- Ran 16 tests in 0.086s FAILED (failures=1, skipped=2) |
|||
| msg128290 - (view) | Author: Mark Dickinson (mark.dickinson) * (Python committer) | Date: 2011年02月10日 13:01 | |
Ha, yes. I commented out the first four tests for zeros of atan in the cmath_testcases.txt file, but failed to notice that they're tested again, later on. And the same goes for atanh. I need to look at this, but I don't have write-access to the Python svn repo at the moment (my home machine is ill). If someone else wants to go through and just comment out all the tests of zeros for atan and atanh in cmath_testcases.txt, please go ahead. The zeros are tested independently within test_cmath (but skipped on systems like AIX where there are known problems with log1p). |
|||
| msg128405 - (view) | Author: Mark Dickinson (mark.dickinson) * (Python committer) | Date: 2011年02月11日 15:45 | |
Here's a patch. |
|||
| msg128557 - (view) | Author: Sébastien Sablé (sable) | Date: 2011年02月14日 16:49 | |
Here is the result after applying that patch: ====================================================================== FAIL: test_specific_values (__main__.CMathTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "Lib/test/test_cmath.py", line 380, in test_specific_values msg=error_message) File "Lib/test/test_cmath.py", line 128, in rAssertAlmostEqual 'got {!r}'.format(a, b)) AssertionError: atanh0225: atanh(complex(-0.0, 5.6067e-320)) Expected: complex(-0.0, 5.6067e-320) Received: complex(0.0, 5.6067e-320) Received value insufficiently close to expected value. ---------------------------------------------------------------------- Ran 16 tests in 0.081s FAILED (failures=1, skipped=2) |
|||
| msg168510 - (view) | Author: Mark Dickinson (mark.dickinson) * (Python committer) | Date: 2012年08月18日 11:35 | |
The fix applied for issue #15477 should also fix this issue. |
|||
| History | |||
|---|---|---|---|
| Date | User | Action | Args |
| 2022年04月11日 14:57:06 | admin | set | github: 54129 |
| 2013年03月14日 13:44:16 | alef | set | nosy:
+ alef |
| 2012年08月18日 11:35:00 | mark.dickinson | set | status: open -> closed messages: + msg168510 versions: + Python 3.3 |
| 2011年02月14日 16:49:05 | sable | set | messages: + msg128557 |
| 2011年02月11日 15:45:19 | mark.dickinson | set | files:
+ issue9920.patch messages: + msg128405 keywords: + patch |
| 2011年02月10日 13:01:37 | mark.dickinson | set | status: closed -> open messages: + msg128290 |
| 2011年02月10日 12:37:55 | sable | set | messages: + msg128287 |
| 2011年01月07日 09:04:00 | mark.dickinson | set | status: pending -> closed |
| 2010年11月20日 11:09:32 | mark.dickinson | set | status: open -> pending resolution: fixed messages: + msg121609 stage: resolved |
| 2010年09月23日 13:15:44 | sable | set | messages: + msg117182 |
| 2010年09月23日 10:36:21 | mark.dickinson | set | messages: + msg117179 |
| 2010年09月23日 09:15:47 | sable | set | messages: + msg117174 |
| 2010年09月22日 14:30:49 | mark.dickinson | set | messages: + msg117144 |
| 2010年09月22日 14:21:15 | mark.dickinson | set | messages: + msg117143 |
| 2010年09月22日 14:19:50 | mark.dickinson | set | assignee: mark.dickinson messages: + msg117142 nosy: + mark.dickinson |
| 2010年09月22日 14:13:06 | sable | create | |