FPU issue when building on i386 or armel #534
Comments
|
There are two different issues here. The second one from the original bug report relates to what you identify above -- which is a test of an expected value of 0. I have pushed in some changes that might address this. The first in the original bug report is a import numpy
with numpy.errstate(invalid="raise"):
numpy.log2(-2)Can you have the original reporter check this please. |
|
Hi, thanks for the quick reply.
On Sun, Feb 16, 2020 at 02:05:41PM -0800, GavinHuttley wrote:
There are two different issues here. The second one from the original bug report relates to what you identify above -- which is a test of an expected value of 0. I have pushed in some changes that *might* address this.
I could apply 96ab670 as a patch to the packaging.
The first in the original bug report is a `numpy` issue. Specifically, the minimal relevant code that should be failing with the `FloatingPointError` is
```python
with numpy.errstate(invalid="raise"):
numpy.log2(-2)
```
Can you have the original reporter check this please.
Hmmm, the initial reporter was just reading the build logs of Debian autobuilders. I could try to login to an armel/i386 machine and check. But this might take some time.
Kind regards, Andreas.
|
|
With patch 96ab670 applied I get on
i386 emulation now only two remaining errors:
======================================================================
FAIL: test_jsd (tests.test_maths.test_measure.TestJensenShannon)
case1 is testing if the jsd between two identical distributions is 0.0
----------------------------------------------------------------------
Traceback (most recent call last):
File "/build/python-cogent-2019.12.6a+dfsg/.pybuild/cpython3_3.8_cogent3/build/tests/test_maths/test_measure.py", line 201, in test_jsd
assert_allclose(
File "/usr/lib/python3/dist-packages/numpy/testing/_private/utils.py", line 1514, in assert_allclose
assert_array_compare(compare, actual, desired, err_msg=str(err_msg),
File "/usr/lib/python3/dist-packages/numpy/testing/_private/utils.py", line 841, in assert_array_compare
raise AssertionError(msg)
AssertionError:
Not equal to tolerance rtol=1e-07, atol=0
Testing case4 for jsd failed
Mismatch: 100%
Max absolute difference: 4.4408921e-16
Max relative difference: inf
x: array(4.440892e-16)
y: array(0.)
======================================================================
FAIL: test_jsm (tests.test_maths.test_measure.TestJensenShannon)
case1 is testing if the jsm between two identical distributions is 0.0
----------------------------------------------------------------------
Traceback (most recent call last):
File "/build/python-cogent-2019.12.6a+dfsg/.pybuild/cpython3_3.8_cogent3/build/tests/test_maths/test_measure.py", line 242, in test_jsm
assert_allclose(
File "/usr/lib/python3/dist-packages/numpy/testing/_private/utils.py", line 1514, in assert_allclose
assert_array_compare(compare, actual, desired, err_msg=str(err_msg),
File "/usr/lib/python3/dist-packages/numpy/testing/_private/utils.py", line 841, in assert_array_compare
raise AssertionError(msg)
AssertionError:
Not equal to tolerance rtol=1e-07, atol=0
Testing case4 for jsm failed
Mismatch: 100%
Max absolute difference: 2.10734243e-08
Max relative difference: inf
x: array(2.107342e-08)
y: array(0.)
----------------------------------------------------------------------
Ran 2246 tests in 74.339s
FAILED (failures=2, skipped=1)
Strangely enough these are different than the ones in the bug report.
The issue does not happen when building on amd64.
On Mon, Feb 17, 2020 at 05:55:32AM +0100, Andreas Tille wrote:
> The first in the original bug report is a `numpy` issue. Specifically, the minimal relevant code that should be failing with the `FloatingPointError` is
>
> ```python
> with numpy.errstate(invalid="raise"):
> numpy.log2(-2)
> ```
> Can you have the original reporter check this please.
I've tried i386 emulation as well as native amd64:
$ python3
Python 3.7.6 (default, Jan 19 2020, 19:20:10)
[GCC 9.2.1 20200110] on linux
Type "help", "copyright", "credits" or "license" for more information.
>> import numpy
>> with numpy.errstate(invalid="raise"):
... numpy.log2(-2)
...
Traceback (most recent call last):
File "<stdin>", line 2, in <module>
FloatingPointError: invalid value encountered in log2
Kind regards, Andreas.
|
GavinHuttley
added a commit
that referenced
this issue
Feb 19, 2020
TST: tweak the atol values for evaluating jsd/jsm cases that produce 0, #534
|
I've pushed in a patch that adjusts the testing precision for these two test cases. However, a better approach is probably to skip these (and other failing tests) on these platforms. Can you try this out and also post the result of the following on these platforms: import sys
print(sys.platform.lower())thanks! |
|
Hi, See at the end of this link for the full build log. |
|
No response for a very long time. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hi,
the Debian package of cogent3 received a bug report about build failures for architectures i386 and armel. The explenation of the bug reporter is:
he armel port has no FPU in the baseline, and the math emulation does not handle all corner cases correctly.
The i386 port uses the 387 FPU that has excess precision.
The full bug log is linked inside the bug report. It burns down to:
I wonder whether you might want to work around this issue in your test suite or whether you might suggest to exclude the said architectures from building.
Kind regards, Andreas.
The text was updated successfully, but these errors were encountered: