There is an error context that controls how floating point signals are handled. There is a separate control for underflow, overflow, divide by zero, and invalid. IIRC, it was decided on this list a while ago to make the default ignore for underflow and warning for overflow, invalid and divide by zero.

However, an oversight pushed versions of NumPy where all the error handlers where set to "ignore" and this test was probably written then. I think the test should be changed to check for RuntimeWarning on some of the cases. This might take a little work as it looks like the code uses generators across multiple tests and would have to be changed to handle expecting warnings.

Alternatively, the error context can be set before the test runs and then restored afterwords:

olderr = np.seterr(invalid='ignore') abs(a) np.seterr(**olderr)

or, using an errstate context ---

with np.errstate(invalid='ignore'): abs(a)

-Travis

On Sep 4, 2012, at 6:24 PM, Ondřej Čertík wrote:

Hi,

When running the test suite, there are problems of this kind:

https://github.com/numpy/numpy/issues/394

which then causes for example the Debian buildbots tests to fail (https://github.com/numpy/numpy/issues/406). The problem is really simple:

...

...

...

from numpy import array, abs, nan a = array([1, nan, 3]) a

array([ 1., nan, 3.])

...

...

...

abs(a)

__main__:1: RuntimeWarning: invalid value encountered in absolute array([ 1., nan, 3.])

See the issue #394 for detailed explanation why "nan" is being passed to abs(). Now the question is, what should the right fix be?

1. Should the runtime warning be disabled?

2. Should the tests be reworked, so that "nan" is not tested in allclose()?

3. Should abs() be fixed to not emit the warning?

4. Should the test suite be somehow fixed not to fail if there are

runtime warnings?

Let me know which direction we should go.

Thanks, Ondrej _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion

The framework for catching errors relies on hardware flags getting set and our C code making the right calls to detect those flags.

This has usually worked correctly in the past --- but it is an area where changes in compilers or platforms could create problems.

We should test to be sure that the correct warnings are issued, I would think. Perhaps using a catch_warnings context would be helpful (from http://docs.python.org/library/warnings.html)

import warnings

def fxn(): warnings.warn("deprecated", DeprecationWarning)

with warnings.catch_warnings(record=True) as w: # Cause all warnings to always be triggered. warnings.simplefilter("always") # Trigger a warning. fxn() # Verify some things assert len(w) == 1 assert issubclass(w[-1].category, DeprecationWarning) assert "deprecated" in str(w[-1].message)

-Travis

On Sep 4, 2012, at 10:49 PM, Ondřej Čertík wrote:

On Tue, Sep 4, 2012 at 8:38 PM, Travis Oliphant travis@continuum.io wrote:

...

There is an error context that controls how floating point signals are handled. There is a separate control for underflow, overflow, divide by zero, and invalid. IIRC, it was decided on this list a while ago to make the default ignore for underflow and warning for overflow, invalid and divide by zero.

However, an oversight pushed versions of NumPy where all the error handlers where set to "ignore" and this test was probably written then. I think the test should be changed to check for RuntimeWarning on some of the cases. This might take a little work as it looks like the code uses generators across multiple tests and would have to be changed to handle expecting warnings.

Alternatively, the error context can be set before the test runs and then restored afterwords:

olderr = np.seterr(invalid='ignore') abs(a) np.seterr(**olderr)

or, using an errstate context ---

with np.errstate(invalid='ignore'): abs(a)

I see --- so abs([nan]) should emit a warning, but in the test we should suppress it. I'll work on that.

The only thing that I don't understand is why it only happens on some platforms and doesn't on some other platforms (apparently). But it's clear how to fix it now.

Thanks for the information.

Ondrej _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion

On Fri, Sep 7, 2012 at 7:54 AM, Ralf Gommers ralf.gommers@gmail.com wrote:

On Wed, Sep 5, 2012 at 7:06 AM, Travis Oliphant travis@continuum.io wrote:

...

The framework for catching errors relies on hardware flags getting set and our C code making the right calls to detect those flags.

This has usually worked correctly in the past --- but it is an area where changes in compilers or platforms could create problems.

I don't think it ever did, for less common platforms at least. See all the Debian test issues that were filed by Sandro this week. And even between Windows and Linux, there are some inconsistencies.

...

We should test to be sure that the correct warnings are issued, I would think. Perhaps using a catch_warnings context would be helpful (from http://docs.python.org/library/warnings.html)

There are some tests for that already, in core/test_numeric.py. For example:

====================================================================== FAIL: test_default (test_numeric.TestSeterr)

---

Traceback (most recent call last): File "/Users/rgommers/Code/numpy/numpy/core/tests/test_numeric.py", line 231, in test_default under='ignore', AssertionError: {'over': 'ignore', 'divide': 'ignore', 'invalid': 'ignore', 'under': 'ignore'} != {'over': 'warn', 'divide': 'warn', 'invalid': 'warn', 'under': 'ignore'}

---

They're not exhaustive though.

...

import warnings

def fxn(): warnings.warn("deprecated", DeprecationWarning)

with warnings.catch_warnings(record=True) as w: # Cause all warnings to always be triggered. warnings.simplefilter("always") # Trigger a warning. fxn() # Verify some things assert len(w) == 1 assert issubclass(w[-1].category, DeprecationWarning) assert "deprecated" in str(w[-1].message)

Use ``from numpy.testing import WarningManager`` for a 2.4-compatible version of catch_warnings (with explicitly calling its __enter__ and __exit__ methods).

In the release 1.7.x branch these warnings are suppressed, but in master they frequently make the Travis tests fail. That's extremely annoying to me, so I started working on a fix here:

https://github.com/numpy/numpy/pull/2745

using the recommendation from Travis above.

Ondrej