test_pareto on 32-bit got even worse #18387

Activity

1. seberg

   added

   component: numpy.random

   on Feb 10, 2021
2. seberg

   added this to the 1.20.2 release milestone on Feb 10, 2021
3. seberg commented on Feb 10, 2021

   

   seberg

   on Feb 10, 2021

   Member

   More actions

   I am surprised anything changed here, but marking for 1.20.2, just so that its not lost by accident. For what its worth, the mailing list link is slightly off for me, and this gives the right one:
   https://mail.python.org/pipermail/numpy-discussion/2012-September/063764.html

   Out of curiosity, do you know that this is a regression in that the 1.19 passed fine with the same compiler versions, etc?
4. bnavigator commented on Feb 10, 2021

   

   bnavigator

   on Feb 10, 2021

   ContributorAuthor

   More actions

   See #18388 for build logs. Here is a passing one for 1.19.5:
   numpy-1.19-i586_log.txt
5. bashtage commented on Feb 11, 2021

   

   bashtage

   on Feb 11, 2021

   Contributor

   More actions

   What is a little interesting is that it doesn't occur in the same test for RandomState. Even though the underlying code is the same, the seeding of the MT19937 generator in the failing file is different from that in the RandomState, and so the test values are different.
6. charris

   removed this from the 1.20.2 release milestone on Mar 27, 2021
7. charris commented on Mar 27, 2021

   

   charris

   on Mar 27, 2021

   Member

   More actions

   I cleared the milestone here. @bashtage Seems this is a value issue/
8. bashtage commented on Mar 27, 2021

   

   bashtage

   on Mar 27, 2021

   Contributor

   More actions

   I think it would be reasonable to relax the tolerance on 32-bit Linux as a pragmatic fix. It seems to be compiler-specific since the test doesn't fail on other 32-bit platforms including other 32-bit variants of Linux.
9. apteryks commented on Apr 19, 2022

   

   apteryks

   on Apr 19, 2022

   More actions

   I also reproduce this on i686-linux (GNU Guix). The test_float_remainder_overflow test also failed there:

   =================================== FAILURES ===================================
   _________________ TestRemainder.test_float_remainder_overflow __________________
   [gw15] linux -- Python 3.9.9 /gnu/store/iabliixhj5hirckni5wr3d75vjfcw74i-python-3.9.9/bin/python3
   
   self = <numpy.core.tests.test_umath.TestRemainder object at 0xf1c7d958>
   
       def test_float_remainder_overflow(self):
           a = np.finfo(np.float64).tiny
           with np.errstate(over='ignore', invalid='ignore'):
               div, mod = np.divmod(4, a)
               np.isinf(div)
               assert_(mod == 0)
           with np.errstate(over='raise', invalid='ignore'):
               assert_raises(FloatingPointError, np.divmod, 4, a)
           with np.errstate(invalid='raise', over='ignore'):
   >           assert_raises(FloatingPointError, np.divmod, 4, a)
   
   a          = 2.2250738585072014e-308
   div        = inf
   mod        = 0.0
   self       = <numpy.core.tests.test_umath.TestRemainder object at 0xf1c7d958>
   
   /gnu/store/vbhm2gxkfhmdx085yy2kkrwc34y40778-python-numpy-1.21.6/lib/python3.9/site-packages/numpy/core/tests/test_umath.py:607: 
   _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
   /gnu/store/iabliixhj5hirckni5wr3d75vjfcw74i-python-3.9.9/lib/python3.9/unittest/case.py:739: in assertRaises
       return context.handle('assertRaises', args, kwargs)
           args       = (<ufunc 'divmod'>, 4, 2.2250738585072014e-308)
           context    = None
           expected_exception = <class 'FloatingPointError'>
           kwargs     = {}
           self       = <numpy.testing._private.utils._Dummy testMethod=nop>
   /gnu/store/iabliixhj5hirckni5wr3d75vjfcw74i-python-3.9.9/lib/python3.9/unittest/case.py:201: in handle
       callable_obj(*args, **kwargs)
           args       = [4, 2.2250738585072014e-308]
           callable_obj = <ufunc 'divmod'>
           kwargs     = {}
           name       = 'assertRaises'
           self       = None
   /gnu/store/iabliixhj5hirckni5wr3d75vjfcw74i-python-3.9.9/lib/python3.9/unittest/case.py:223: in __exit__
       self._raiseFailure("{} not raised by {}".format(exc_name,
           exc_name   = 'FloatingPointError'
           exc_type   = None
           exc_value  = None
           self       = <unittest.case._AssertRaisesContext object at 0xf1c7dcd0>
           tb         = None
   _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
   
   self = <unittest.case._AssertRaisesContext object at 0xf1c7dcd0>
   standardMsg = 'FloatingPointError not raised by divmod'
   
       def _raiseFailure(self, standardMsg):
           msg = self.test_case._formatMessage(self.msg, standardMsg)
   >       raise self.test_case.failureException(msg)
   E       AssertionError: FloatingPointError not raised by divmod
   
   msg        = 'FloatingPointError not raised by divmod'
   self       = <unittest.case._AssertRaisesContext object at 0xf1c7dcd0>
   standardMsg = 'FloatingPointError not raised by divmod'
   
   /gnu/store/iabliixhj5hirckni5wr3d75vjfcw74i-python-3.9.9/lib/python3.9/unittest/case.py:163: AssertionError
   __________________________ TestRandomDist.test_pareto __________________________
   [gw2] linux -- Python 3.9.9 /gnu/store/iabliixhj5hirckni5wr3d75vjfcw74i-python-3.9.9/bin/python3
   
   self = <numpy.random.tests.test_generator_mt19937.TestRandomDist object at 0x8fee2340>
   
       def test_pareto(self):
           random = Generator(MT19937(self.seed))
           actual = random.pareto(a=.123456789, size=(3, 2))
           desired = np.array([[1.0394926776069018e+00, 7.7142534343505773e+04],
                               [7.2640150889064703e-01, 3.4650454783825594e+05],
                               [4.5852344481994740e+04, 6.5851383009539105e+07]])
           # For some reason on 32-bit x86 Ubuntu 12.10 the [1, 0] entry in this
           # matrix differs by 24 nulps. Discussion:
           #   https://mail.python.org/pipermail/numpy-discussion/2012-September/063801.html
           # Consensus is that this is probably some gcc quirk that affects
           # rounding but not in any important way, so we just use a looser
           # tolerance on this test:
   >       np.testing.assert_array_almost_equal_nulp(actual, desired, nulp=30)
   E       AssertionError: X and Y are not equal to 30 ULP (max is 31)
   
   actual     = array([[1.03949268e+00, 7.71425343e+04],
          [7.26401509e-01, 3.46504548e+05],
          [4.58523445e+04, 6.58513830e+07]])
   desired    = array([[1.03949268e+00, 7.71425343e+04],
          [7.26401509e-01, 3.46504548e+05],
          [4.58523445e+04, 6.58513830e+07]])
   random     = Generator(MT19937) at 0xEEDC8028
   self       = <numpy.random.tests.test_generator_mt19937.TestRandomDist object at 0x8fee2340>
   
   /gnu/store/vbhm2gxkfhmdx085yy2kkrwc34y40778-python-numpy-1.21.6/lib/python3.9/site-packages/numpy/random/tests/test_generator_mt19937.py:1528: AssertionError
   =========================== short test summary info ============================
   FAILED ../../core/tests/test_umath.py::TestRemainder::test_float_remainder_overflow
   FAILED ../../random/tests/test_generator_mt19937.py::TestRandomDist::test_pareto
   = 2 failed, 15026 passed, 623 skipped, 18 xfailed, 4 xpassed in 189.89s (0:03:09) =