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.
with warnings.catch_warnings(record=True) as w:
# Cause all warnings to always be triggered.
# Trigger a warning.
# Verify some things
assert len(w) == 1
assert issubclass(w[-1].category, DeprecationWarning)
assert "deprecated" in str(w[-1].message)
On Sep 4, 2012, at 10:49 PM, Ondřej Čertík wrote:
On Tue, Sep 4, 2012 at 8:38 PM, Travis Oliphant <firstname.lastname@example.org
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')
or, using an errstate context ---
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.
NumPy-Discussion mailing listNumPy-Discussion@scipy.org