[Numpy-discussion] Added atleast_nd, request for clarification/cleanup of atleast_3d

[Joseph Fox-Rabinovitz]

Hi,

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.

Regards,

    -Joe



On Mon, Jul 11, 2016 at 10:41 AM, Joseph Fox-Rabinovitz <
jfoxrabinovitz at gmail.com> wrote:

> 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 at gmail.com> wrote:
> > On Thu, Jul 7, 2016 at 4:34 AM, Sebastian Berg
> > <sebastian at 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 at 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 at scipy.org
> >>> > > https://mail.scipy.org/mailman/listinfo/numpy-discussion
> >>> > _______________________________________________
> >>> > NumPy-Discussion mailing list
> >>> > NumPy-Discussion at scipy.org
> >>> > https://mail.scipy.org/mailman/listinfo/numpy-discussion
> >>> >
> >>> _______________________________________________
> >>> NumPy-Discussion mailing list
> >>> NumPy-Discussion at scipy.org
> >>> https://mail.scipy.org/mailman/listinfo/numpy-discussion
> >>
> >> _______________________________________________
> >> NumPy-Discussion mailing list
> >> NumPy-Discussion at scipy.org
> >> https://mail.scipy.org/mailman/listinfo/numpy-discussion
> >>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20161027/1be25b94/attachment.html>