<br><br><div class="gmail_quote">On Sat, May 16, 2009 at 2:02 AM, Eric Firing <span dir="ltr">&lt;<a href="mailto:efiring@hawaii.edu">efiring@hawaii.edu</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 class="im">Charles R Harris wrote:<br>
&gt;<br>
&gt;<br>
&gt; On Fri, May 15, 2009 at 7:48 PM, Eric Firing &lt;<a href="mailto:efiring@hawaii.edu">efiring@hawaii.edu</a><br>
</div><div class="im">&gt; &lt;mailto:<a href="mailto:efiring@hawaii.edu">efiring@hawaii.edu</a>&gt;&gt; wrote:<br>
&gt;<br>
&gt;<br>
&gt;     <a href="http://www.mail-archive.com/numpy-discussion@scipy.org/msg17595.html" target="_blank">http://www.mail-archive.com/numpy-discussion@scipy.org/msg17595.html</a><br>
&gt;<br>
&gt;     Prompted by the thread above, I decided to see what it would take to<br>
&gt;     implement ufuncs with masking in C.  I described the result here:<br>
&gt;<br>
&gt;     <a href="http://www.mail-archive.com/numpy-discussion@scipy.org/msg17698.html" target="_blank">http://www.mail-archive.com/numpy-discussion@scipy.org/msg17698.html</a><br>
&gt;<br>
&gt;     Now I am starting a new thread. The present state of the work is now in<br>
&gt;     github:  <a href="http://github.com/efiring/numpy-work/tree/cfastma" target="_blank">http://github.com/efiring/numpy-work/tree/cfastma</a><br>
&gt;<br>
&gt;     I don&#39;t want to do any more until I have gotten some feedback from core<br>
&gt;     developers.  (And I would be delighted if someone wants to help with<br>
&gt;     this, or take it over.)<br>
<br>
</div>Chuck,<br>
<br>
Thanks very much for the quick response.<br>
<div class="im"><br>
&gt;<br>
&gt;<br>
&gt; Here the if ... continue needs to follow the declaration:<br>
&gt;<br>
&gt;         if (*mp1) continue;<br>
&gt;         float in1 = *(float *)ip1;<br>
&gt;         float in2 = *(float *)ip2;<br>
&gt;         *(float *)op1 = f(in1, in2);<br>
&gt;<br>
<br>
</div>I was surprised to see the declarations inside the loop in the first<br>
place (this certainly is not ANSI-C), and I was also pleasantly<br>
surprised that letting them be after the conditional didn&#39;t seem to<br>
bother the compiler at all.  Maybe that is a gcc extension.<br>
<div class="im"></div></blockquote><div><br>Declarations at the top of a block have always been valid C.<br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im"><br>
&gt; I think this would be better as<br>
&gt;<br>
&gt;         if (!(*mp1)) {<br>
&gt;             float in1 = *(float *)ip1;<br>
&gt;             float in2 = *(float *)ip2;<br>
&gt;             *(float *)op1 = f(in1, in2);<br>
&gt;         }<br>
&gt;<br>
<br>
</div>I agree, and I thought of that originally--I think I did it with<br>
continue because it was easier to type it in, and it reduced the<br>
difference relative to the non-masked form.<br>
<div class="im"><br>
&gt;<br>
&gt; But since this is actually a ternary function, you could define new<br>
&gt; functions, something like<br>
&gt;<br>
&gt; double npy_add_m(double a, double b, double mask)<br>
&gt; {<br>
&gt;     if (!mask) {<br>
&gt;         return a + b;<br>
&gt;     else {<br>
&gt;         return a;<br>
&gt;     }<br>
&gt; }<br>
&gt;<br>
&gt; And use the currently existing loops. Well, you would have to add one<br>
&gt; for ternary functions.<br>
&gt;<br>
</div>That would incur the overhead of an extra function call for each<br>
element; I suspect it would slow it down a lot. My motivation is to make<br>
masked array overhead negligible, at least for medium to large arrays.<br>
</blockquote><div><br>It overhead would be the same as it is now, the generic loops all use passed function pointers for functions like sin. Some functions like addition, which is intrinsic and not part of a library, are done in their own special loops that you will find further down in that file. The difficulty I see is that with the current machinery the mask will be converted to the same type as the added numbers and that could add some overhead.<br>
 <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
Also your suggestion above does not handle the case where an output<br>
argument is supplied; it would modify the output under the mask.<br>
<div class="im"><br>
&gt; Question, what about reduce? I don&#39;t think it is defined defined for<br>
&gt; ternary functions. Apart from reduce, why not just add, you already have<br>
&gt; the mask to tell you which results are invalid.<br>
&gt;<br>
<br>
</div>You mean just do the operation and ignore the results under the mask?<br>
This is the way Pierre originally did it, if I remember correctly, but<br>
fairly recently people started objecting that they didn&#39;t want to<br>
disturb values in an output argument under a mask.  So now ma jumps<br>
through hoops to satisfy this requirement, and it is consequently slow.<br>
</blockquote><div><br>OK. I&#39;m not familiar with the uses of masked arrays.<br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
ufunc methods like reduce are supported only for the binary ops with one<br>
output, so they are automatically unavailable for the masked versions.<br>
To get around this would require subclassing the ufunc to make a masked<br>
version.  This is probably the best way to go, but I suspect it is much<br>
more complicated than I can handle in the amount of time I can spend.<br>
</blockquote><div><br>I think reduce could be added for ternary functions, but it is a design decision how it should operate.<br><br>Chuck<br></div><br></div><br>