On Fri, 2021-02-12 at 10:08 -0500, Robert Kern wrote: > On Fri, Feb 12, 2021 at 9:45 AM Joseph Fox-Rabinovitz < > jfoxrabinov...@gmail.com> wrote: > > > > > > > On Fri, Feb 12, 2021, 09:32 Robert Kern <robert.k...@gmail.com> > > wrote: > > > > > On Fri, Feb 12, 2021 at 5:15 AM Eric Wieser < > > > wieser.eric+nu...@gmail.com> > > > wrote: > > > > > > > > There might be some linear algebraic reason why those axis > > > > > positions > > > > make sense, but I’m not aware of it... > > > > > > > > My guess is that the historical motivation was to allow > > > > grayscale `(H, > > > > W)` images to be converted into `(H, W, 1)` images so that they > > > > can be > > > > broadcast against `(H, W, 3)` RGB images. > > > > > > > > > > Correct. If you do introduce atleast_nd(), I'm not sure why you'd > > > deprecate and remove the one existing function that *isn't* made > > > redundant > > > thereby. > > > > > > > `atleast_nd` handles the promotion of 2D to 3D correctly. The `pos` > > argument lets you tell it where to put the new axes. What's > > unintuitive to > > my is that the 1D case gets promoted to from shape `(x,)` to shape > > `(1, x, > > 1)`. It takes two calls to `atleast_nd` to replicate that behavior. > > > > When thinking about channeled images, the channel axis is not of the > same > kind as the H and W axes. Really, you tend to want to think about an > RGB > image as a (H, W) array of colors rather than an (H, W, 3) ndarray of > intensity values. As much as possible, you want to treat RGB images > similar > to (H, W)-shaped grayscale images. Let's say I want to make a > separable > filter to convolve with my image, that is, we have a 1D filter for > each of > the H and W axes, and they are repeated for each channel, if RGB. > Setting > up a separable filter for (H, W) grayscale is straightforward with > broadcasting semantics. I can use (ntaps,)-shaped vector for the W > axis and > (ntaps, 1)-shaped filter for the H axis. Now, when I go to the RGB > case, I > want the same thing. atleast_3d() adapts those correctly for the (H, > W, > nchannels) case.
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. The `pos` argument is the current solution to this, but maybe is a better way [2]? Meshgrid for example defaults to `indexing='xy'` and has `indexing='ij'` for a similar purpose [1]. Of course, if `atleast_3d` is common enough, I guess that argument could also swing to adding a keyword-only argument to `atleast_3d` (that way we can/will never change the default). - Sebastian [1] Not sure the purposes are comparable, but in both cases, they provide information about the "context" in which meshgrid/atleast_3d are used. [2] It feels a bit like you may have to think about what `pos=3` will actually do (in the sense, that we will all just end up doing trial and error :)). At which point I am not sure there is too much gained over the surprise of `atleast_3d`. > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion@python.org > https://mail.python.org/mailman/listinfo/numpy-discussion
signature.asc
Description: This is a digitally signed message part
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
