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