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 jfoxrabinovitz@gmail.com wrote:

On Thu, Jul 7, 2016 at 4:34 AM, Sebastian Berg sebastian@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 efiring@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