<div class="gmail_quote">On Wed, Jun 24, 2009 at 3:37 PM, Charles R Harris <span dir="ltr"><<a href="mailto:charlesr.harris@gmail.com">charlesr.harris@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><div></div><div class="h5">On Wed, Jun 24, 2009 at 8:52 AM, Darren Dale<<a href="mailto:dsdale24@gmail.com">dsdale24@gmail.com</a>> wrote:<br>
> On Wed, Jun 24, 2009 at 9:42 AM, Charles R Harris<br>
> <<a href="mailto:charlesr.harris@gmail.com">charlesr.harris@gmail.com</a>> wrote:<br>
>><br>
>> On Wed, Jun 24, 2009 at 7:08 AM, Darren Dale<<a href="mailto:dsdale24@gmail.com">dsdale24@gmail.com</a>> wrote:<br>
>> > On Wed, May 27, 2009 at 11:30 AM, Darren Dale <<a href="mailto:dsdale24@gmail.com">dsdale24@gmail.com</a>><br>
>> > wrote:<br>
>> >><br>
>> >> Now that numpy-1.3 has been released, I was hoping I could engage the<br>
>> >> numpy developers and community concerning my suggestion to improve the<br>
>> >> ufunc<br>
>> >> wrapping mechanism. Currently, ufuncs call, on the way out, the<br>
>> >> __array_wrap__ method of the input array with the highest<br>
>> >> __array_priority__.<br>
>> >><br>
>> >> There are use cases, like masked arrays or arrays with units, where it<br>
>> >> is<br>
>> >> imperative to run some code on the way in to the ufunc as well.<br>
>> >> MaskedArrays<br>
>> >> do this by reimplementing or wrapping ufuncs, but this approach puts<br>
>> >> some<br>
>> >> pretty severe constraints on subclassing. For example, in my Quantities<br>
>> >> package I have a Quantity object that derives from ndarray. It has been<br>
>> >> suggested that in order to make ufuncs work with Quantity, I should<br>
>> >> wrap<br>
>> >> numpy's built-in ufuncs. But I intend to make a MaskedQuantity object<br>
>> >> as<br>
>> >> well, deriving from MaskedArray, and would therefore have to wrap the<br>
>> >> MaskedArray ufuncs as well.<br>
>> >><br>
>> >> If ufuncs would simply call a method both on the way in and on the way<br>
>> >> out, I think this would go a long way to improving this situation. I<br>
>> >> whipped<br>
>> >> up a simple proof of concept and posted it in this thread a while back.<br>
>> >> For<br>
>> >> example, a MaskedQuantity would implement a method like __gfunc_pre__<br>
>> >> to<br>
>> >> check the validity of the units operation etc, and would then call<br>
>> >> MaskedArray.__gfunc_pre__ (if defined) to determine the domain etc.<br>
>> >> __gfunc_pre__ would return a dict containing any metadata the<br>
>> >> subclasses<br>
>> >> wish to provide based on the inputs, and that dict would be passed<br>
>> >> along<br>
>> >> with the inputs, output and context to __gfunc_post__, so<br>
>> >> postprocessing can<br>
>> >> be done (__gfunc_post__ replacing __array_wrap__).<br>
>> >><br>
>> >> Of course, packages like MaskedArray may still wish to reimplement<br>
>> >> ufuncs,<br>
>> >> like Eric Firing is investigating right now. The point is that classes<br>
>> >> that<br>
>> >> dont care about the implementation of ufuncs, that only need to provide<br>
>> >> metadata based on the inputs and the output, can do so using this<br>
>> >> mechanism<br>
>> >> and can build upon other specialized arrays.<br>
>> >><br>
>> >> I would really appreciate input from numpy developers and other<br>
>> >> interested<br>
>> >> parties. I would like to continue developing the Quantities package<br>
>> >> this<br>
>> >> summer, and have been approached by numerous people interested in using<br>
>> >> Quantities with sage, sympy, matplotlib. But I would prefer to improve<br>
>> >> the<br>
>> >> ufunc mechanism (or establish that there is no interest among the<br>
>> >> community<br>
>> >> to do so) so I can improve the package (or limit its scope) before<br>
>> >> making an<br>
>> >> official announcement.<br>
>> ><br>
>> > There was some discussion of this proposal to allow better interaction<br>
>> > of<br>
>> > ufuncs with ndarray subclasses in another thread (Plans for numpy-1.4.0<br>
>> > and<br>
>> > scipy-0.8.0) and the comments were encouraging. I have been trying to<br>
>> > gather<br>
>> > feedback as to whether the numpy devs were receptive to the idea, and it<br>
>> > seems the answer is tentatively yes, although there were questions about<br>
>> > who<br>
>> > would actually write the code. I guess I have not made clear that I<br>
>> > intend<br>
>> > to write the implementation and tests. I gained some familiarity with<br>
>> > the<br>
>> > relevant code while squashing a few bugs for numpy-1.3, but it would be<br>
>> > helpful if someone else who is familiar with the existing __array_wrap__<br>
>> > machinery would be willing to discuss this proposal in more detail and<br>
>> > offer<br>
>> > constructive criticism along the way. Is anyone willing?<br>
>> ><br>
>><br>
>> I think Travis would be the only one familiar with that code and that<br>
>> would be from a couple of years back when he wrote it. Most of us have<br>
>> followed the same route as yourself, finding our way into the code by<br>
>> squashing bugs.<br>
>><br>
><br>
> Do you mean that you would require Travis to sign off on the implementation<br>
> (assuming he would agree to review my work)? I would really like to avoid a<br>
> situation where I invest the time and then the code bitrots because I can't<br>
> find a route to committing it to svn.<br>
><br>
<br>
</div></div>No, just that Travis would know the most about that subsystem if you<br>
are looking for help. I and others here can look over the code and<br>
commit it without Travis signing off on it. You could ask for commit<br>
privileges yourself. The important thing is having some tests and an<br>
agreement that the interface is appropriate. Pierre also seems<br>
interested in the functionality so it would be useful for him to say<br>
that it serves his needs also.<br>
<div><div></div><div class="h5"></div></div></blockquote><div><br>Ok, I'll start working on it then. Any idea what you are targeting for numpy-1.4? Scipy-2009, or much earlier? I'd like to gauge how to budget my time.<br>
<br>Darren <br></div></div>