Bug 2339539
Summary: | gnofract4d fails to build with Python 3.14: AssertionError: 'ct_sin6 = (0.841471,-0)' != 'ct_sin6 = (0.841471,0)' | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Karolina Surma <ksurma> | ||||
Component: | gnofract4d | Assignee: | Yaakov Selkowitz <yselkowi> | ||||
Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
Severity: | unspecified | Docs Contact: | |||||
Priority: | unspecified | ||||||
Version: | rawhide | CC: | fti-bugs, ksurma, mhroncok, yselkowi | ||||
Target Milestone: | --- | ||||||
Target Release: | --- | ||||||
Hardware: | Unspecified | ||||||
OS: | Unspecified | ||||||
Whiteboard: | |||||||
Fixed In Version: | gnofract4d-4.3-21.fc43 | Doc Type: | If docs needed, set a value | ||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2025-06-11 19:09:16 UTC | Type: | Bug | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Bug Depends On: | |||||||
Bug Blocks: | 2322407, 2339432, 2339435 | ||||||
Attachments: |
|
Description
Karolina Surma
2025-01-22 15:55:11 UTC
-0 vs. 0, just lovely... Any mathematicians around to explain that? I'm afraid I could use some help with that. FWIW, this just successfully rebuilt for the F42 mass rebuild. $ python3.13 -c 'from cmath import sin; print(sin(1-0j))' (0.8414709848078965+0j) $ python3.14 -c 'from cmath import sin; print(sin(1-0j))' (0.8414709848078965-0j) I am no math expert, but I think both results are de facto correct. We can bisect Python to see where this happened if it helps. commit 987311d42e3ec838de8ff27f9f0575aa791a6bde Author: Sergey B Kirpichev <skirpichev> Date: Tue Nov 26 18:57:39 2024 +0300 gh-69639: Add mixed-mode rules for complex arithmetic (C-like) (GH-124829) "Generally, mixed-mode arithmetic combining real and complex variables should be performed directly, not by first coercing the real to complex, lest the sign of zero be rendered uninformative; the same goes for combinations of pure imaginary quantities with complex variables." (c) Kahan, W: Branch cuts for complex elementary functions. This patch implements mixed-mode arithmetic rules, combining real and complex variables as specified by C standards since C99 (in particular, there is no special version for the true division with real lhs operand). Most C compilers implementing C99+ Annex G have only these special rules (without support for imaginary type, which is going to be deprecated in C2y). https://github.com/python/cpython/commit/987311d42e3ec838de8ff27f9f0575aa791a6bde https://github.com/python/cpython/pull/124829 https://github.com/python/cpython/issues/69639 ---- I don't know if the -0 thing is a desired result of this or an accidental one. This bug appears to have been reported against 'rawhide' during the Fedora Linux 42 development cycle. Changing version to 42. Created attachment 2093177 [details] Possible patch The relevant code appears to be: ``` def cpredict(self, f, arg=(1 + 0j)): try: z = f(arg) return "(%.6g,%.6g)" % (z.real, z.imag) except OverflowError: return "(inf,inf)" except ZeroDivisionError: return "(nan,nan)" except ValueError: return "(inf,inf)" def make_test(self, myfunc, pyfunc, val, n): codefrag = "ct_%s%d = %s((%d,%d))" % ( myfunc, n, myfunc, val.real, val.imag) lookat = "ct_%s%d" % (myfunc, n) result = self.cpredict(pyfunc, val) return [codefrag, lookat, result] def manufacture_tests(self, myfunc, pyfunc): vals = [0 + 0j, 0 + 1j, 1 + 0j, 1 + 1j, 3 + 2j, 1 - 0j, 0 - 1j, -3 + 2j, -2 - 2j, -1 + 0j] return [self.make_test(myfunc, pyfunc, x_y[0], x_y[1]) for x_y in zip(vals, list(range(1, len(vals))))] ``` It's the `1 - 0j` iteration that's failing. So I think what's happening here is that, while the sign is being preserved by Python initially (as of 3.14), it's not being preserved elsewhere: 1) it is not preserved when passed through the "%d" formatting of `make_test`, e.g.: >>> val = 1 - 0j >>> val (1-0j) >>> val.imag -0.0 >>> print("%d" % val.imag) 0 2) it is not being preserved by C++ and/or gf4d; note other places marked `CONSIDER` in the sources which need to be fixed due to mismatches. The simplest workaround appears to be to skip the 1-0j iteration, per the attached patch which I tested in the side tag: https://koji.fedoraproject.org/koji/taskinfo?taskID=133610276 I'm open to suggestions though. *** Bug 2371720 has been marked as a duplicate of this bug. *** |