On Wed, Jul 6, 2016 at 3:29 AM, <josef.p...@gmail.com> wrote: > > > On Wed, Jul 6, 2016 at 2:21 AM, Ralf Gommers <ralf.gomm...@gmail.com> > wrote: > >> >> >> On Wed, Jul 6, 2016 at 7:06 AM, Nathaniel Smith <n...@pobox.com> wrote: >> >> On Jul 5, 2016 9:09 PM, "Joseph Fox-Rabinovitz" <jfoxrabinov...@gmail.com> >>> wrote: >>> > >>> > Hi, >>> > >>> > I have generalized np.atleast_1d, np.atleast_2d, np.atleast_3d with a >>> > function np.atleast_nd in PR#7804 >>> > (https://github.com/numpy/numpy/pull/7804). >>> > >>> > As a result of this PR, I have a couple of questions about >>> > `np.atleast_3d`. `np.atleast_3d` appears to do something weird with >>> > the dimensions: If the input is 1D, it prepends and appends a size-1 >>> > dimension. If the input is 2D, it appends a size-1 dimension. This is >>> > inconsistent with `np.atleast_2d`, which always prepends (as does >>> > `np.atleast_nd`). >>> > >>> > - Is there any reason for this behavior? >>> > - Can it be cleaned up (e.g., by reimplementing `np.atleast_3d` in >>> > terms of `np.atleast_nd`, which is actually much simpler)? This would >>> > be a slight API change since the output would not be exactly the same. >>> >>> Changing atleast_3d seems likely to break a bunch of stuff... >>> >>> Beyond that, I find it hard to have an opinion about the best design for >>> these functions, because I don't think I've ever encountered a situation >>> where they were actually what I wanted. I'm not a big fan of coercing >>> dimensions in the first place, for the usual "refuse to guess" reasons. And >>> then generally if I do want to coerce an array to another dimension, then I >>> have some opinion about where the new dimensions should go, and/or I have >>> some opinion about the minimum acceptable starting dimension, and/or I have >>> a maximum dimension in mind. (E.g. "coerce 1d inputs into a column matrix; >>> 0d or 3d inputs are an error" -- atleast_2d is zero-for-three on that >>> requirements list.) >>> >>> I don't know how typical I am in this. But it does make me wonder if the >>> atleast_* functions act as an attractive nuisance, where new users take >>> their presence as an implicit recommendation that they are actually a >>> useful thing to reach for, even though they... aren't that. And maybe we >>> should be recommending folk move away from them rather than trying to >>> extend them further? >>> >>> Or maybe they're totally useful and I'm just missing it. What's your use >>> case that motivates atleast_nd? >>> >> I think you're just missing it:) atleast_1d/2d are used quite a bit in >> Scipy and Statsmodels (those are the only ones I checked), and in the large >> majority of cases it's the best thing to use there. There's a bunch of >> atleast_2d calls with a transpose appended because the input needs to be >> treated as columns instead of rows, but that's still efficient and readable >> enough. >> > > > As Ralph pointed out its usage in statsmodels. I do find them useful as > replacement for several lines of ifs and reshapes > > We stilll need in many cases the atleast_2d_cols, that appends the newaxis > if necessary. > > roughly the equivalent of > > if x.ndim == 1: > x = x[:, None] > else: > x = np.atleast_2d(x) > > Josef > > >> >> For 3D/nD I can see that you'd need more control over where the >> dimensions go, but 1D/2D are fine. >> >
statsmodels has currently very little code with ndim >2, so I have no overview of possible use cases, but it would be necessary to have full control over the added axis since axis have a strict meaning and stats still prefer Fortran order to default numpy/C ordering. Josef > >> >> Ralf >> >> >> _______________________________________________ >> 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
