[Numpy-discussion] Release blockers for 1.4.0 ?

Charles R Harris charlesr.harris@gmail....
Tue Dec 8 08:36:02 CST 2009


On Tue, Dec 8, 2009 at 12:31 AM, David Cournapeau <
david@ar.media.kyoto-u.ac.jp> wrote:

> 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.

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.scipy.org/pipermail/numpy-discussion/attachments/20091208/45e924d2/attachment-0001.html 


More information about the NumPy-Discussion mailing list