<div dir="ltr"><div><div>Hi,<br><br></div>I would like to revitalize the discussion on including PR#7804 (atleast_nd function) at Stephan Hoyer's request. atleast_nd has come up as a convenient workaround for #8206 (adding padding options to diff) to be able to do broadcasting with the required dimensions reversed.<br><br></div><div>Regards,<br></div><div><br></div>    -Joe<br><br><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jul 11, 2016 at 10:41 AM, Joseph Fox-Rabinovitz <span dir="ltr"><<a href="mailto:jfoxrabinovitz@gmail.com" target="_blank">jfoxrabinovitz@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I would like to follow up on my original PR (7804). While there<br>
appears to be some debate as to whether the PR is numpy material to<br>
begin with, there do not appear to be any technical issues with it. To<br>
make the decision more straightforward, I factored out the<br>
non-controversial bug fixes to masked arrays into PR #7823, along with<br>
their regression tests. This way, the original enhancement can be<br>
closed or left hanging indefinitely, (even though I hope neither<br>
happens). PR 7804 still has the bug fixes duplicated in it.<br>
<br>
Regards,<br>
<br>
    -Joe<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
On Thu, Jul 7, 2016 at 9:11 AM, Joseph Fox-Rabinovitz<br>
<<a href="mailto:jfoxrabinovitz@gmail.com">jfoxrabinovitz@gmail.com</a>> wrote:<br>
> On Thu, Jul 7, 2016 at 4:34 AM, Sebastian Berg<br>
> <<a href="mailto:sebastian@sipsolutions.net">sebastian@sipsolutions.net</a>> wrote:<br>
>> On Mi, 2016-07-06 at 15:30 -0400, Benjamin Root wrote:<br>
>>> I don't see how one could define a spec that would take an arbitrary<br>
>>> array of indices at which to place new dimensions. By definition, you<br>
>>><br>
>><br>
>> You just give a reordered range, so that (1, 0, 2) would be the current<br>
>> 3D version. If 1D, fill in `1` and `2`, if 2D, fill in only `2` (0D,<br>
>> add everything of course).<br>
><br>
> I was originally thinking (-1, 0) for the 2D case. Just go along the<br>
> list and fill as many dims as necessary. Your way is much better since<br>
> it does not require a different operation for positive and negative<br>
> indices.<br>
><br>
>> However, I have my doubts that it is actually easier to understand then<br>
>> to write yourself ;).<br>
><br>
> A dictionary or ragged list would be better for that: either {1: (1,<br>
> 0), 2: (2,)} or [(1, 0), (2,)]. The first is more clear since the<br>
> index in the list is the starting ndim - 1.<br>
><br>
>><br>
>> - Sebastian<br>
>><br>
>><br>
>>> don't know how many dimensions are going to be added. If you knew,<br>
>>> then you wouldn't be calling this function. I can only imagine simple<br>
>>> rules such as 'left' or 'right' or maybe something akin to what<br>
>>> at_least3d() implements.<br>
>>><br>
>>> On Wed, Jul 6, 2016 at 3:20 PM, Joseph Fox-Rabinovitz <jfoxrabinovitz<br>
>>> @<a href="http://gmail.com" rel="noreferrer" target="_blank">gmail.com</a>> wrote:<br>
>>> > On Wed, Jul 6, 2016 at 2:57 PM, Eric Firing <<a href="mailto:efiring@hawaii.edu">efiring@hawaii.edu</a>><br>
>>> > wrote:<br>
>>> > > On 2016/07/06 8:25 AM, Benjamin Root wrote:<br>
>>> > >><br>
>>> > >> I wouldn't have the keyword be "where", as that collides with<br>
>>> > the notion<br>
>>> > >> of "where" elsewhere in numpy.<br>
>>> > ><br>
>>> > ><br>
>>> > > Agreed.  Maybe "side"?<br>
>>> ><br>
>>> > I have tentatively changed it to "pos". The reason that I don't<br>
>>> > like<br>
>>> > "side" is that it implies only a subset of the possible ways that<br>
>>> > that<br>
>>> > the position of the new dimensions can be specified. The current<br>
>>> > implementation only puts things on one side or the other, but I<br>
>>> > have<br>
>>> > considered also allowing an array of indices at which to place new<br>
>>> > dimensions, and/or a dictionary keyed by the starting ndims. I do<br>
>>> > not<br>
>>> > think "side" would be appropriate for these extended cases, even if<br>
>>> > they are very unlikely to ever materialize.<br>
>>> ><br>
>>> >     -Joe<br>
>>> ><br>
>>> > > (I find atleast_1d and atleast_2d to be very helpful for handling<br>
>>> > inputs, as<br>
>>> > > Ben noted; I'm skeptical as to the value of atleast_3d and<br>
>>> > atleast_nd.)<br>
>>> > ><br>
>>> > > Eric<br>
>>> > ><br>
>>> > > ______________________________<wbr>_________________<br>
>>> > > NumPy-Discussion mailing list<br>
>>> > > <a href="mailto:NumPy-Discussion@scipy.org">NumPy-Discussion@scipy.org</a><br>
>>> > > <a href="https://mail.scipy.org/mailman/listinfo/numpy-discussion" rel="noreferrer" target="_blank">https://mail.scipy.org/<wbr>mailman/listinfo/numpy-<wbr>discussion</a><br>
>>> > ______________________________<wbr>_________________<br>
>>> > NumPy-Discussion mailing list<br>
>>> > <a href="mailto:NumPy-Discussion@scipy.org">NumPy-Discussion@scipy.org</a><br>
>>> > <a href="https://mail.scipy.org/mailman/listinfo/numpy-discussion" rel="noreferrer" target="_blank">https://mail.scipy.org/<wbr>mailman/listinfo/numpy-<wbr>discussion</a><br>
>>> ><br>
>>> ______________________________<wbr>_________________<br>
>>> NumPy-Discussion mailing list<br>
>>> <a href="mailto:NumPy-Discussion@scipy.org">NumPy-Discussion@scipy.org</a><br>
>>> <a href="https://mail.scipy.org/mailman/listinfo/numpy-discussion" rel="noreferrer" target="_blank">https://mail.scipy.org/<wbr>mailman/listinfo/numpy-<wbr>discussion</a><br>
>><br>
>> ______________________________<wbr>_________________<br>
>> NumPy-Discussion mailing list<br>
>> <a href="mailto:NumPy-Discussion@scipy.org">NumPy-Discussion@scipy.org</a><br>
>> <a href="https://mail.scipy.org/mailman/listinfo/numpy-discussion" rel="noreferrer" target="_blank">https://mail.scipy.org/<wbr>mailman/listinfo/numpy-<wbr>discussion</a><br>
>><br>
</div></div></blockquote></div><br></div>