<br><br><div class="gmail_quote">On Tue, Apr 23, 2013 at 4:06 PM, Sebastian Berg <span dir="ltr">&lt;<a href="mailto:sebastian@sipsolutions.net" target="_blank">sebastian@sipsolutions.net</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Tue, 2013-04-23 at 17:08 -0400, Frédéric Bastien wrote:<br>
&gt; Hi,<br>
&gt;<br>
&gt; this is currently used in Theano! In fact, it is a John S. that<br>
&gt; implemented it in NumPy to allow fast gradient of the advanced<br>
&gt; indexing in Theano. It allow code like:<br>
&gt;<br>
&gt;<br>
&gt; matrix1[vector1, vector2] += matrix2<br>
&gt;<br>
</div>Yes, I had missed that and thought maybe nobody actually used it yet. I<br>
gave some points why I think there should be some changes in the<br>
original pull request [1]. Mostly I think it would make sense (also a<br>
lot for theano) to rewrite it with the new iterators and expose the<br>
subspace more directly. That would give vast speedups for mixed<br>
fancy/non-fancy indices.<br>
<br>
But if this is useful to you, I guess one can also just create a new one<br>
if someone finds time, leaving the old MapIter deprecated and<br>
unmaintained.<br>
<br>
[1] <a href="https://github.com/numpy/numpy/pull/377" target="_blank">https://github.com/numpy/numpy/pull/377</a><br>
<div class="im"><br>
&gt; where there is duplicate indices in the vector<br>
&gt;<br>
&gt; In looking at the code, I saw it use at least those part of the<br>
&gt; interface.<br>
&gt;<br>
&gt; PyArrayMapIterObject<br>
&gt; PyArray_MapIterNext<br>
&gt; PyArray_ITER_NEXT<br>
&gt; PyArray_MapIterSwapAxes<br>
&gt; PyArray_BroadcastToShape<br>
&gt;<br>
<br>
</div>There is likely no reason for changing these, but improving MapIter<br>
would likely break binary compatibility because of struct access.<br>
<span class="HOEnZb"><font color="#888888"><br>
- Sebastian<br>
</font></span><div class="HOEnZb"><div class="h5">&gt;<br>
&gt; I lost the end of this discussion, but I think this is not possible in<br>
&gt; NumPy as there was not an agreement to include that. But I remember a<br>
&gt; few other user on this list asking for this(and they where Theano user<br>
&gt; to my knowledge).<br>
&gt;<br>
&gt;<br>
&gt; So I would prefer that you don&#39;t remove the part that we use for the<br>
&gt; next 1.8 release.<br>
&gt;<br>
&gt; thanks<br>
&gt;<br>
&gt; Frédéric<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; On Tue, Apr 16, 2013 at 9:54 AM, Nathaniel Smith &lt;<a href="mailto:njs@pobox.com">njs@pobox.com</a>&gt;<br>
&gt; wrote:<br>
&gt;         On Mon, Apr 15, 2013 at 5:29 PM, Sebastian Berg<br>
&gt;         &lt;<a href="mailto:sebastian@sipsolutions.net">sebastian@sipsolutions.net</a>&gt; wrote:<br>
&gt;         &gt; Hey,<br>
&gt;         &gt;<br>
&gt;         &gt; the MapIter API has only been made public in master right?<br>
&gt;         So it is no<br>
&gt;         &gt; problem at all to change at least the mapiter struct, right?<br>
&gt;         &gt;<br>
&gt;         &gt; I got annoyed at all those special cases that make things<br>
&gt;         difficult to<br>
&gt;         &gt; get an idea where to put i.e. to fix the boolean array-like<br>
&gt;         stuff. So<br>
&gt;         &gt; actually started rewriting it (and I already got one big<br>
&gt;         function that<br>
&gt;         &gt; does all index preparation -- ok it is untested but its<br>
&gt;         basically<br>
&gt;         &gt; there).<br>
&gt;         &gt;<br>
&gt;         &gt; I would guess it is not really a big problem even if it was<br>
&gt;         public for<br>
&gt;         &gt; longer, since you shouldn&#39;t do those direct struct access<br>
&gt;         probably? But<br>
&gt;         &gt; just checking.<br>
&gt;<br>
&gt;<br>
&gt;         Why don&#39;t we just make the struct opaque, i.e., just declare<br>
&gt;         it in the<br>
&gt;         public header file and move the actual definition to an<br>
&gt;         internal<br>
&gt;         header file?<br>
&gt;<br>
&gt;         If it&#39;s too annoying I guess we could even make it non-public,<br>
&gt;         at<br>
&gt;         least in 1.8 -- IIRC it&#39;s only there so we can use it in<br>
&gt;         umath, and<br>
&gt;         IIRC the patch to use it hasn&#39;t landed yet. Or we could just<br>
&gt;         merge<br>
&gt;         umath and multiarray into a single .so, that would save a<br>
&gt;         *lot* of<br>
&gt;         annoying fiddling with the public API that doesn&#39;t actually<br>
&gt;         serve any<br>
&gt;         purpose.<br>
&gt;<br></div></div></blockquote><div><br>Does this have any overlap with <a href="https://github.com/numpy/numpy/pull/2821">https://github.com/numpy/numpy/pull/2821</a> ?<br><br>Chuck <br></div><br></div>