test_complex.test_truediv can fail

[encukou]

Bug report

Bug description:

test_truediv has the following check:

        # Just for fun.
        for i in range(100):
            self.check_div(complex(random(), random()),
                           complex(random(), random()))

where check_div(x, y) checks that (x * y) / y is "close" to x.

This recently failed on AMD64 Arch Linux Usan Function with:

./python -m test test_complex -m test_truediv --randseed 1627284292

It fails with 1e-09 for the first random number and 1 for the rest.

Looks like a test bug but it might be better if a float/complex expert takes a look around here. @skirpichev, is this interesting for you?

CPython versions tested on:

CPython main branch

Operating systems tested on:

Linux

[vstinner]

The failure occurs for example for these numbers:

        self.check_div(complex(8.289760544677449e-09, 0.13257307440728516),
                       complex(0.9059966714925808, 0.5054864708672686))

[encukou]

Or self.check_div(complex(1e-09, 1), complex(1, 1)), as I wrote.

[skirpichev]

Looks as a test bug. Error analysis for complex division is tricky, I don't see why used error bound is valid.

[skirpichev]

So, the test was added by 0f33604, when naive complex division algorithm was replaced by Smith's code. CC @tim-one

"A Note on Complex Division" mentions that relative error is the same order of magnitude as math.ulp(1). Though, similar not holds component-wise. But check_div() actually tests relative errors for components with some arbitrary looking measure of closeness (eps=1e-9).

I think we should use rather tests like abs(q - x)/abs(x) < eps for q = z / y (and similar for q = z / x). Similar inequalities for components could be easily broken (though, it's not too simple for a random input), for example:

>>> import math
>>> x, y = 1e-9+1j, 1+1j
>>> (((x*y)/y).real - x.real)/math.ulp(x.real)
131672427.0