![](https://secure.gravatar.com/avatar/5f88830d19f9c83e2ddfd913496c5025.jpg?s=120&d=mm&r=g)
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). Ralf
-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
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion