testHypot in test_match uses assertEqual on floats

[mcepl]

https://github.com/python/cpython/blob/main/Lib/test/test_math.py#L794-L871

We (SUSE) have test self.assertEqual(hypot(1, -1), math.sqrt(2)) failing on some distros and some architectures (namely i586) and I suspect that whole idea of assertEqual on two floating point numbers is very unfortunate. Shouldn't be there at least assertAlmostEqual?

Cc: @mdickinson, @rhettinger, @danigm

Linked PRs

• gh-124040: adjust few tests in testHypot/testDist to get exactly computed results #124042
• [3.13] gh-124040: Adjust few tests in testHypot/testDist to get exactly computed results (GH-124042) #124235
• [3.12] gh-124040: Adjust few tests in testHypot/testDist to get exactly computed results (GH-124042) #124236

[Eclips4]

cc @skirpichev as the author of c61de45

[skirpichev]

IIRC, this test error condition for PyLong_AsDouble/PyFloat_AsDouble (-1 is returned without exception set). I think that we could just drop 1st argument.

I'll double check that & propose a patch.

Edit: using assertAlmostEqual seems ok for me, but most tests in the testHypot() use carefully chosen arguments to compare computed values exactly.

[skirpichev]

pr is ready for review: #124042

[danigm]

There's another similar tests that fails with the same error:

FAIL: testDist (test.test_math.MathTests.testDist)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/abuild/rpmbuild/BUILD/Python-3.13.0rc2/Lib/test/test_math.py", line 972, in testDist
    self.assertEqual(dist((True, True, False, True, False),
    ~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
                          (True, False, True, True, False)),
                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
                     sqrt(2.0))
                     ^^^^^^^^^^
AssertionError: 1.414213562373095 != 1.4142135623730951

[skirpichev]

Ah, that's from 9c18b1a. I think we could just add two units:

diff --git a/Lib/test/test_math.py b/Lib/test/test_math.py
index c93876e701..dba017a9bb 100644
--- a/Lib/test/test_math.py
+++ b/Lib/test/test_math.py
@@ -969,9 +969,9 @@ def testDist(self):
         self.assertEqual(dist((D(14), D(1)), (D(2), D(-4))), D(13))
         self.assertEqual(dist((F(14, 32), F(1, 32)), (F(2, 32), F(-4, 32))),
                          F(13, 32))
-        self.assertEqual(dist((True, True, False, True, False),
-                              (True, False, True, True, False)),
-                         sqrt(2.0))
+        self.assertEqual(dist((True, True, False, False, True, True),
+                              (True, False, True, False, False, False)),
+                         2.0)
 
         # Test corner cases
         self.assertEqual(dist((13.25, 12.5, -3.25),

[mdickinson]

I suspect that whole idea of assertEqual on two floating point numbers is very unfortunate.

I believe that the algorithm that @rhettinger implemented for math.hypot has proven and strong error guarantees (though I don't recall whether it guarantees correct rounding or not), but those error guarantees depend on an assumption of strict IEEE 754 semantics. So in the presence of strict IEEE 754 semantics, it doesn't seem inappropriate to be using assertEqual to check hypot results in cases where the error guarantees imply that we should be getting perfect results.

Note that CPython these days does require that the C double type underlying Python's float uses IEEE 754 binary64 format, but that requirement isn't enough to guarantee that the arithmetic operations on doubles follow strict IEEE 754 rules.

At a guess, the problem on i586 is that we don't have strict IEEE 754 semantics, because we're making use of the x87 floating-point instructions (with the 80-bit x87 floating-point format) and so ending up with double rounding on some arithmetic operations.

The other possible cause here is that the code is using FMA/FMS instructions where it shouldn't be (or conversely, is not using FMA/FMS instructions where it's expected to). But my bet's on x87 arithmetic and double rounding.

Possibly we should find a way to detect the x87/double-rounding situation and either skip or weaken the precise tests on machines that have that issue. There's precedent for this elsewhere in the Python test suite (e.g., in the tests for math.fsum, which only guarantees correctly-rounded results in the absence of x87-induced double rounding).

[skirpichev]

@mcepl, could you add decorator

@unittest.skipIf(HAVE_DOUBLE_ROUNDING, "")

on top of testHypot/testDist and test again?

@mdickinson, thank you for reply.

here's precedent for this elsewhere in the Python test suite

E.g. testHypotAccuracy(). But tests in testHypot/testDist are more basic: sanity checks for arguments, etc. I don't think that filtering out these test functions is a good idea.

BTW, Tim Peters told us, that you are resigned as a core developer (I hope, that my bad pr's weren't at least partially a reason). Yet you are listed in devguide in the expert index. Is it still ok to mention you in relevant topics?

[mdickinson]

Yet you are listed in devguide in the expert index.

Ah, thanks for pointing that out. I've opened a PR to fix that: python/devguide#1397

Is it still ok to mention you in relevant topics?

Sure, mention away! I may not always have time to respond, though.

[danigm]

pr is ready for review: #124042

I can confirm that this PR solves all the issues.