BUG,TST: Fix condition for whether long double is “IBM double double”.#31375
Open
manueljacob wants to merge 1 commit into
Open
BUG,TST: Fix condition for whether long double is “IBM double double”.#31375manueljacob wants to merge 1 commit into
manueljacob wants to merge 1 commit into
Conversation
7a76cdc to
ed5f56c
Compare
Some distributions changed the default for long double on 64-bit PowerPC (at least little-endian) from the “IBM double double” format to the IEEE 754 binary128 format. The implementation already handles that by detecting the format at build time (longdouble_format property). Before this change, the tests checked only the CPU architecture name, possibly falsely assuming that long double has the “IBM double double” format when it actually has the IEEE 754 binary128 format. After this change, the tests assume the “IBM double double” format only if the maximum value, determined by calling numpy.finfo(), is the maximum value characteristic for the “IBM double double” format. On CPU architectures other than PowerPC, the “IBM double double” format is never assumed. I found no evidence that any other CPU architecture ever used that format. On a system where long double has the “IBM double double” format, the test results don’t change: 47406 passed, 1047 skipped, 2845 deselected, 32 xfailed, 4 xpassed On a system where long double has the IEEE 754 binary128 format, the test results change from: 1 failed, 47404 passed, 1049 skipped, 2845 deselected, 32 xfailed, 4 xpassed to: 47408 passed, 1048 skipped, 2845 deselected, 32 xfailed, 2 xpassed Fixes numpy#21094.
ed5f56c to
eba6eab
Compare
seberg
approved these changes
May 11, 2026
Member
seberg
left a comment
There was a problem hiding this comment.
Makes sense to me, I would prefer to tweak the definition slightly. If I have a good idea, I might also just apply that.
|
|
||
| LONG_DOUBLE_IS_IBM_DOUBLE_DOUBLE = (platform.machine().startswith("ppc") | ||
| and str(np.finfo(np.longdouble).max) | ||
| == "1.79769313486231580793728971405301e+308") |
Member
There was a problem hiding this comment.
Would it make sense to just drop the PPC entirely? I would also slightly prefer to nmant (or even also nexp), not quite as distinct in theory, but then we don't have to trust string formatters (I don't really trust them, although I guess that one test would maybe fail if they failed)...
(A bit pattern would work as well, but one special value or two seems distinct enough, I would agree.)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Some distributions changed the default for long double on 64-bit PowerPC (at least little-endian) from the “IBM double double” format to the IEEE 754 binary128 format. The implementation already handles that by detecting the format at build time (longdouble_format property). Before this change, the tests checked only the CPU architecture name, possibly falsely assuming that long double has the “IBM double double” format when it actually has the IEEE 754 binary128 format. After this change, the tests assume the “IBM double double” format only if the maximum value, determined by calling numpy.finfo(), is the maximum value characteristic for the “IBM double double” format. On CPU architectures other than PowerPC, the “IBM double double” format is never assumed. I found no evidence that any other CPU architecture ever used that format.
On a system where long double has the “IBM double double” format, the test results don’t change:
47406 passed, 1047 skipped, 2845 deselected, 32 xfailed, 4 xpassed
On a system where long double has the IEEE 754 binary128 format, the test results change from:
1 failed, 47404 passed, 1049 skipped, 2845 deselected, 32 xfailed, 4 xpassed
to:
47408 passed, 1048 skipped, 2845 deselected, 32 xfailed, 2 xpassed
Fixes #21094.
First time committer introduction
I rarely use NumPy directly. I encountered one of the previous test failures when building the NumPy package in the Nix package collection (which runs the tests).
AI Disclosure
No AI tools used