Add explicit test for a misbehaving math.floor

This commit is contained in:
Nick Coghlan 2007-07-26 14:03:00 +00:00
parent c473149a5a
commit 00f2029cd5
2 changed files with 7 additions and 6 deletions

View File

@ -92,6 +92,10 @@ class MathTests(unittest.TestCase):
self.ftest('floor(-0.5)', math.floor(-0.5), -1)
self.ftest('floor(-1.0)', math.floor(-1.0), -1)
self.ftest('floor(-1.5)', math.floor(-1.5), -2)
# pow() relies on floor() to check for integers
# This fails on some platforms - so check it here
self.ftest('floor(1.23e167)', math.floor(1.23e167), 1.23e167)
self.ftest('floor(-1.23e167)', math.floor(-1.23e167), -1.23e167)
def testFmod(self):
self.assertRaises(TypeError, math.fmod)

View File

@ -106,12 +106,9 @@ class PowTest(unittest.TestCase):
# platform pow() was buggy, and Python didn't worm around it.
eq = self.assertEquals
a = -1.0
# XXX Temporary diagnostic for failure on alpha Debian buildbot
from sys import __stdout__
from math import floor
print >> __stdout__, "*** Number: %r" % 1.23e167
print >> __stdout__, "*** Floor: %r" % floor(1.23e167)
# XXX End diagnostic message
# The next two tests can still fail if the platform floor()
# function doesn't treat all large inputs as integers
# test_math should also fail if that is happening
eq(pow(a, 1.23e167), 1.0)
eq(pow(a, -1.23e167), 1.0)
for b in range(-10, 11):