On Mar 17, 2010, at 5:43 PM, Charles R Harris wrote: > > > > On Wed, Mar 17, 2010 at 3:13 PM, Darren Dale <dsdal...@gmail.com> wrote: > On Wed, Mar 17, 2010 at 4:48 PM, Pierre GM <pgmdevl...@gmail.com> wrote: > > On Mar 17, 2010, at 8:19 AM, Darren Dale wrote: > >> > >> I started thinking about a third method called __input_prepare__ that > >> would be called on the way into the ufunc, which would allow you to > >> intercept the input and pass a somehow modified copy back to the > >> ufunc. The total flow would be: > >> > >> 1) Call myufunc(x, y[, z]) > >> 2) myufunc calls ?.__input_prepare__(myufunc, x, y), which returns x', > >> y' (or simply passes through x,y by default) > >> 3) myufunc creates the output array z (if not specified) and calls > >> ?.__array_prepare__(z, (myufunc, x, y, ...)) > >> 4) myufunc finally gets around to performing the calculation > >> 5) myufunc calls ?.__array_wrap__(z, (myufunc, x, y, ...)) and returns > >> the result to the caller > >> > >> Is this general enough for your use case? I haven't tried to think > >> about how to change some global state at one point and change it back > >> at another, that seems like a bad idea and difficult to support. > > > > > > Sounds like a good plan. If we could find a way to merge the first two > > (__input_prepare__ and __array_prepare__), that'd be ideal. > > I think it is better to keep them separate, so we don't have one > method that is trying to do too much. It would be easier to explain in > the documentation. > > I may not have much time to look into this until after Monday. Is > there a deadline we need to consider? > > > I don't think this should go into 2.0, I think it needs more thought. And > 2.0 already has significant code churn. Is there any reason beyond a big > hassle not to set/restore the error state around all the ufunc calls in ma?
Should be done with r8295. Please let me know whether I missed one. Otherwise, I agree with Chuck. Let's take some time to figure something. It'd be significant a change that it shouldn't go in 2.0 _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion