[Numpy-discussion] Release blockers for 1.4.0 ?

[David Cournapeau]

Pierre GM wrote:
> A bit of background first;
> In the first implementations of numpy.core.ma, the approach was to get rid of the data that could cause problem beforehand by replacing them with safe values. Turned out that finding these data is not always obvious (cf the problem of defining a domain when dealing with exponents that we discussed a while back on this list), and that all in all, it is faster to compute first and deal with the problems afterwards. Of course, the user doesn't need the warnings if something goes wrong, so disabling them globally looked like a way to go. I thought the disabling would be only for numpy.ma, though

I don't think there is an easy (or any) way to disable this at module
level. Please be sure to always do so in a try/finally (like you would
handle a file object to guarantee it is always closed, for example),
because otherwise, test failures and SIGINT (ctrl+C) will pollute the
user environment.

>
> Anyhow, running numpy.ma.test() on 1.5.x, I get 36 warnings by getting rid of the np.seterr(all='ignore') in numpy.ma.core. I can go down to 2 by saving the seterr state before the computations in _Masked/DomainUnary/BinaryOperation and restoring it after the computation. I gonna try to find where the 2 missing warnings come from.
> The 281 tests + 36 warnings take 4.087s to run, the 2 warning version 5.95s (but I didn't try to go to much into timing details...)

Setting/unsetting the FPU state definitely has a cost. I don't know how
significant it would be for your precise case, though: is the cost
because of setting/unsetting the state in the test themselves or ? We
may be able to improve the situation later on once we have better numbers.

A proper solution to this FPU exception may require hard work (because
of the inherent asynchronous nature of signals, because signals behave
very differently on different platforms, and because I don't think we
can afford spending too many cycles on it).

>
> So, what do you want me to do guys ? Commit the fixes to the trunk ? Backporting them to 1.4.x ?

I have already committed the removal of the global np.seterr in the
trunk. I feel like backporting this one to 1.4.x is a good idea (because
it could be considered as a regression), but maybe someone has a strong
case against it.

cheers,

David