WIP/MAINT: core: Restore float128 power on Mac OSX. #15074
Conversation
7451d8a to
4df3918
Compare
4df3918 to
2b8c408
Compare
| # Check that we are using more than double precision. | ||
| v = np.float128(2) ** 16383 | ||
| assert_allclose(v, np.float128('5.9486574767861588254e+4931')) | ||
|
|
There was a problem hiding this comment.
Do we expect the second test to fail on any platform with 'float128'? I.e., why not skipif(not hasattr(np, 'float128'),
There was a problem hiding this comment.
It is possible that there are (or will be) other platforms that have also implemented power for float128 by falling back to the double precision version. Currently, this test will fail if it is run on the ppc64le platform on Travis-CI. So for now, the test is restricted to Mac OSX/Darwin.
There was a problem hiding this comment.
As long as we are fixing, could we fix it for ppy64le as well?
There was a problem hiding this comment.
I started working on this because I have a Mac, so it seemed like it would be straightforward to fix. The feclearexcept(FE_ALL_EXCEPT) hack shows that, even on the platform for which the problem was originally reported, it is not as easy as it seemed it should be. Without having a ppc64le computer to work on directly, testing and debugging means lots of guess work, and repeatedly running tests via our CI suite. That's pretty inefficient, and probably not a good use of time and computer resources.
There was a problem hiding this comment.
Without having a ppc64le computer to work on directly,
You should be eligible for the gcc compile farm machines, which do include ppc64le machines that are suitable for iterative work, see here: https://cfarm.tetaneutral.net/users/new/
I've been using them & they are pretty great machines.
| // This shouldn't be necessary, but without it, unit tests on some | ||
| // of the Mac OSX CI platforms raise a divide-by-zero warning with | ||
| // a call such as `np.array([0, 1, 2], dtype=np.float128) ** 4`. | ||
| feclearexcept(FE_ALL_EXCEPT); |
There was a problem hiding this comment.
Is this entirely without effect for future calcalations in C / Numpy?
There was a problem hiding this comment.
No, and that is a problem, because the internal ufunc code only checks the flags at the end of an inner loop. For example, this should generate RuntimeWarning: invalid value encountered in power, but it does not:
In [24]: np.array([-1, 0], dtype=np.float128) ** 2.5
Out[24]: array([nan, 0.], dtype=float128)
With float64, the warning is generated:
In [25]: np.array([-1.0, 0.0]) ** 2.5
/Users/warren/mc37numpy/bin/ipython:1: RuntimeWarning: invalid value encountered in power
#!/Users/warren/mc37numpy/bin/python
Out[25]: array([nan, 0.])
The call of feclearexcept(FE_ALL_EXCEPT) is a hack to get the tests on azure to pass. The tests pass on my computer (Mac OSX 10.12.6) without that call, and I was surprised that they didn't pass on the azure Mac OSX test suite. Somehow, even with the custom version of npy_power, calling np.power with float128 data containing 0 and with positive exponents on the azure OSX platform results in a divide-by-zero warning.
P.S. I added "WIP" back to the PR title.
There was a problem hiding this comment.
The macos azure image seems to be this one which is documented as using xcode 11.1 as default but also has other versions. Maybe the bug has been fixed in the version you are using?
There was a problem hiding this comment.
Thanks Matti. My version is old: Xcode 9.2. (I'm running OSX 10.12.6 on a 2013 Macbook Pro. When I upgraded the OS earlier this year, I tried using a newer version of OSX but ran into problems. 10.12.6 has been working fine.)
The use of the math library powl was blacklisted on Mac OSX (numpygh-8318) because powl(0, y) would trigger a divide-by-zero warning even when y > 0 (issue numpygh-8307). This change creates npy_powl on OSX that avoids the spurious warning by not calling powl when x = 0 and y > 0. The change in npy_math_internal.h.src moves the handling of pow out of a template repeat-loop, so powl and powf are handled individually. This allows the creation of npy_powl to be specialized when NPY_OS_DARWIN is defined. Closes numpygh-8608.
52bba80 to
9875e47
Compare
|
It would be nice to fix the blacklisting of numpy/numpy/core/src/common/npy_config.h Lines 94 to 97 in 6c38e05 but I will not likely get back to this PR any time soon, so I'm closing it. |
The use of the math library
powlwas blacklisted on Mac OSX(gh-8318) because
powl(0, y)would trigger a divide-by-zerowarning even when y > 0 (issue gh-8307).
This change creates
npy_powlon OSX that avoids the spuriouswarning by not calling
powlwhen x = 0 and y > 0.The change in
npy_math_internal.h.srcmoves the handlingof
powout of a template repeat-loop, sopowlandpowfare handled individually. This allows the creation of
npy_powlto be specialized whenNPY_OS_DARWINis defined.Closes gh-8608.