On Fri, Feb 12, 2021 at 3:42 PM Ralf Gommers <ralf.gomm...@gmail.com> wrote:
> > On Fri, Feb 12, 2021 at 9:21 PM Robert Kern <robert.k...@gmail.com> wrote: > >> On Fri, Feb 12, 2021 at 1:47 PM Ralf Gommers <ralf.gomm...@gmail.com> >> wrote: >> >>> >>> On Fri, Feb 12, 2021 at 7:25 PM Sebastian Berg < >>> sebast...@sipsolutions.net> wrote: >>> >>>> >>>> Right, my initial feeling it that without such context `atleast_3d` is >>>> pretty surprising. So I wonder if we can design `atleast_nd` in a way >>>> that it is explicit about this context. >>>> >>> >>> Agreed. I think such a use case is probably too specific to design a >>> single function for, at least in such a hardcoded way. >>> >> >> That might be an argument for not designing a new one (or at least not >> giving it such a name). Not sure it's a good argument for removing a >> long-standing one. >> > > I agree. I'm not sure deprecating is best. But introducing new > functionality where `nd(pos=3) != 3d` is also not great. > > At the very least, atleast_3d should be better documented. It also is > telling that Juan (a long-time) scikit-image dev doesn't like atleast_3d > and there's very little usage of it in scikit-image. > I'm fairly neutral on atleast_nd(). I think that for n=1 and n=2, you can derive The One Way to Do It from broadcasting semantics, but for n>=3, I'm not sure there's much value in trying to systematize it to a single convention. I think that once you get up to those dimensions, you start to want to have domain-specific semantics. I do agree that, in retrospect, atleast_3d() probably should have been named more specifically. It was of a piece of other conveniences like dstack() that did special things to support channel-last images (and implicitly treat 3D arrays as such). For example, DL frameworks that assemble channeled images into minibatches (with different conventions like BHWC and BCHW), you'd want the n=4 behavior to do different things. I _think_ you'd just want to do those with different functions than a complicated set of arguments to one function. -- Robert Kern
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
