Mark expected failures of test_math, test_cmath and test_round as such.

[mdickinson]

BPO	7251
Nosy	@smontanaro, @mdickinson

^{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:

assignee = 'https://github.com/mdickinson'
closed_at = <Date 2009-11-15.15:47:37.817>
created_at = <Date 2009-11-02.09:43:03.608>
labels = ['tests']
title = 'Mark expected failures of test_math, test_cmath and test_round as such.'
updated_at = <Date 2010-08-21.19:18:24.565>
user = 'https://github.com/mdickinson'

bugs.python.org fields:

activity = <Date 2010-08-21.19:18:24.565>
actor = 'mark.dickinson'
assignee = 'mark.dickinson'
closed = True
closed_date = <Date 2009-11-15.15:47:37.817>
closer = 'mark.dickinson'
components = ['Tests']
creation = <Date 2009-11-02.09:43:03.608>
creator = 'mark.dickinson'
dependencies = []
files = []
hgrepos = []
issue_num = 7251
keywords = ['buildbot']
message_count = 11.0
messages = ['94821', '94823', '94894', '94903', '94925', '94927', '94992', '95090', '95092', '95300', '114548']
nosy_count = 3.0
nosy_names = ['skip.montanaro', 'mark.dickinson', 'rpetrov']
pr_nums = []
priority = 'normal'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue7251'
versions = ['Python 2.7', 'Python 3.2']

[mdickinson]

There are some buildbot failures due to platform-specific bugs that need
to be marked as expected failures, using the unittest.expectedFailure
decorator. This may require reorganizing the tests slightly.

• tanh(-0.0) produces 0.0 instead of -0.0 on FreeBSD 6; this causes
  test_math and test_cmath to fail. E.g.,

http://www.python.org/dev/buildbot/builders/x86%20FreeBSD%20trunk/builds/2741

• the libm round function on Debian alpha seems to be buggy; this
  causes test_round in test_builtin.py to fail. E.g.,

http://www.python.org/dev/buildbot/builders/alpha%20Debian%20trunk/builds/30

[mdickinson]

Oops. I meant 'platform' bugs, not 'platform-specific' bugs. These are
not bugs in Python, but in the underlying C library.

[smontanaro]

For 2.6.4 I get a test_float failure on Solaris as well:

test test_float failed -- Traceback (most recent call last):
 File "/home/tuba/skipm/src/python/Python-2.6.4/Lib/test/test_float.py",
line 765, in test_roundtrip
   self.identical(-x, roundtrip(-x))
 File "/home/tuba/skipm/src/python/Python-2.6.4/Lib/test/test_float.py",
line 375, in identical
   self.fail('%r not identical to %r' % (x, y))
AssertionError: -0.0 not identical to 0.0

Haven't looked at 2.7 or 3.1 yet, but it seems to fall into the same
class of test failures as the tanh(-0.0) critter.

[rpetrov]

May be one day python modules will deal with TANH_PRESERVES_ZERO_SIGN
set by configure check.

[mdickinson]

Skip, that looks like a float.hex failure. I'm not sure what the
underlying problem is here; my best guess is that it's something to do
with the copysign function. Please could you tell me what the Solaris
results are for the following interactive session? (Results shown are on
OS X 10.5.)

Python 2.6.4+ (release26-maint:76116, Nov  5 2009, 13:30:59) 
[GCC 4.0.1 (Apple Inc. build 5490)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import math
>>> (-0.0).hex()
'-0x0.0p+0'
>>> float.fromhex((-0.0).hex())
-0.0
>>> math.copysign(1.0, -0.0)
-1.0

Also, is HAVE_COPYSIGN defined in pyconfig.h?

[mdickinson]

May be one day python modules will deal with TANH_PRESERVES_ZERO_SIGN
set by configure check.

Maybe. I added that configure check mainly as a diagnostic, to verify a
suspected cause of test failures. I'm not sure to what degree it's worth
working around system libm bugs in the Python source: an explosion of
#ifdefs in mathmodule.c and cmathmodule.c would reduce readability and
maintainability.

[mdickinson]

The test_round failure on Debian alpha is likely related to this glibc
bug:

http://sources.redhat.com/bugzilla/show_bug.cgi?id=5350

[mdickinson]

The round tests for large values have been broken out into their own test;
this test is now skipped (only if it would fail) on Linux/alpha. See
r76176 (trunk), r76177 (py3k) and r76178 (release31-maint).

The round function itself needs fixing in release26-maint: issue bpo-7070.

[mdickinson]

The round function in release26-maint is fixed (r76179). I'm not sure
whether the round_large test needs to be skipped for release26-maint,
since the Python 2.6 version of round doesn't use the libm round
function.

[mdickinson]

The tanh-related failures are no longer happening, since the FreeBSD
buildbot was upgraded from FreeBSD 6.2 to FreeBSD 6.4.

I'm still worried by Skip's report, but that's a separate issue.

Closing.

[mdickinson]

Postscript: the failure Skip reported looks like a duplicate of bpo-9069, which was tracked down to a gcc compiler bug in gcc 4.4.x (x <= 4) and gcc 4.5.x (x <= 0). That compiler bug is now fixed.