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