<div dir="ltr">Two of the oldest issues in the tracker (<a href="https://github.com/numpy/numpy/issues/834">#834</a> and <a href="https://github.com/numpy/numpy/issues/835">#835</a>) are about how <font face="monospace, monospace">.reduceat()</font> handles its <font face="monospace, monospace">indices</font> parameter. I have been taking a look at the source code, and it would be relatively easy to modify, the hardest part being to figure out what the exact behavior should be.<div><br></div><div>Current behavior is that <font face="monospace, monospace">np.ufunc.reduceat(x, ind)</font> returns <font face="monospace, monospace">[np.ufunc.reduce(a[ind[i]:ind[i+1]] for i in range(len(ind))]</font> with a couple of caveats:</div><div><ol><li>if <font face="monospace, monospace">ind[i] >= ind[i+1]</font>, then <font face="monospace, monospace">a[ind[i]]</font> is returned, rather than a reduction over an empty slice.<br></li><li>an index of <font face="monospace, monospace">len(ind)</font> is appended to the indices argument, to be used as the endpoint of the last slice to reduce over.<br></li><li>aside from this last case, the indices are required to be strictly inbounds, <font face="monospace, monospace">0 <= index < len(x)</font>, or an error is raised<br></li></ol><div>The proposed new behavior, with some optional behaviors, would be:</div><div><ol><li>if <font face="monospace, monospace">ind[i] >= ind[i+1]</font>, then a reduction over an empty slice, i.e. the ufunc identity, is returned. This includes raising an error if the ufunc does not have an identity, e.g. <font face="monospace, monospace">np.minimum</font>.<br></li><li>to fully support the "reduction over slices" idea, some form of out of bounds indices should be allowed. This could mean either that:</li><ol><li>only <font face="monospace, monospace">index = len(x)</font> is allowed without raising an error, to allow computing the full reduction anywhere, not just as the last entry of the return, or<br></li><li>allow any index in <font face="monospace, monospace">-len(x) <= index <= len(x)</font>, with the usual meaning given to negative values, or</li><li>any index is allowed, with reduction results clipped to existing values (and the usual meaning for negative values).</li></ol><li>Regarding the appending of that last index of len(ind) to indices, we could:</li><ol><li>keep appending it, or</li><li>never append it, since you can now request it without an error being raised, or</li><li>only append it if the last index is smaller than <font face="monospace, monospace">len(x)</font>.</li></ol></ol><div>My thoughts on the options:</div><div><ul><li>The minimal, more conservative approach would go with 2.1 and 3.1. And of course 1, if we don't implement that none of this makes sense.</li><li>I kind of think 2.2 or even 2.3 are a nice enhancement that shouldn't break too much stuff.</li><li>3.2 I'm not sure about, probably hurts more than it helps at this point, although in a brand new design you probably would either not append the last index or also prepend a zero, as in <font face="monospace, monospace">np.split</font>.</li><li>And 3.3 seems too magical, probably not a good idea, only listed it for completeness.</li></ul></div></div><div>Any other thoughts or votes on what, if anything, should we implement, and what the deprecation of current behavior should look like?</div><div><br></div><div>Jaime</div><div><br></div>-- <br><div class="gmail_signature">(\__/)<br>( O.o)<br>( > <) Este es Conejo. Copia a Conejo en tu firma y ayúdale en sus planes de dominación mundial.</div>
</div></div>