<div class="gmail_quote">On Wed, Jun 24, 2009 at 9:42 AM, 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 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>> 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 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 is<br>
>> imperative to run some code on the way in to the ufunc as well. MaskedArrays<br>
>> do this by reimplementing or wrapping ufuncs, but this approach puts 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 wrap<br>
>> numpy's built-in ufuncs. But I intend to make a MaskedQuantity object 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 whipped<br>
>> up a simple proof of concept and posted it in this thread a while back. For<br>
>> example, a MaskedQuantity would implement a method like __gfunc_pre__ 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 subclasses<br>
>> wish to provide based on the inputs, and that dict would be passed along<br>
>> with the inputs, output and context to __gfunc_post__, so postprocessing can<br>
>> be done (__gfunc_post__ replacing __array_wrap__).<br>
>><br>
>> Of course, packages like MaskedArray may still wish to reimplement ufuncs,<br>
>> like Eric Firing is investigating right now. The point is that classes 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 mechanism<br>
>> and can build upon other specialized arrays.<br>
>><br>
>> I would really appreciate input from numpy developers and other interested<br>
>> parties. I would like to continue developing the Quantities package 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 the<br>
>> ufunc mechanism (or establish that there is no interest among the community<br>
>> to do so) so I can improve the package (or limit its scope) before making an<br>
>> official announcement.<br>
><br>
> There was some discussion of this proposal to allow better interaction of<br>
> ufuncs with ndarray subclasses in another thread (Plans for numpy-1.4.0 and<br>
> scipy-0.8.0) and the comments were encouraging. I have been trying to 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 who<br>
> would actually write the code. I guess I have not made clear that I intend<br>
> to write the implementation and tests. I gained some familiarity with 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 offer<br>
> constructive criticism along the way. Is anyone willing?<br>
><br>
<br>
</div></div>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></blockquote><div><br>Do you mean that you would require Travis to sign off on the implementation (assuming he would agree to review my work)? I would really like to avoid a situation where I invest the time and then the code bitrots because I can't find a route to committing it to svn.<br>
<br><br>Darren</div></div>