[Numpy-discussion] Release blockers for 1.4.0 ?
Charles R Harris
Tue Dec 8 08:36:02 CST 2009
On Tue, Dec 8, 2009 at 12:31 AM, 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.
At this point it isn't a regression, it is a tradition. I think it best to
leave the fix out of 1.4 and make the change for 1.5 because it is likely to
break user code.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the NumPy-Discussion