<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jul 6, 2016 at 7:06 AM, Nathaniel Smith <span dir="ltr"><<a href="mailto:njs@pobox.com" target="_blank">njs@pobox.com</a>></span> wrote:<br><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><p dir="ltr">On Jul 5, 2016 9:09 PM, "Joseph Fox-Rabinovitz" <<a href="mailto:jfoxrabinovitz@gmail.com" target="_blank">jfoxrabinovitz@gmail.com</a>> wrote:<br>
><br>
> Hi,<br>
><br>
> I have generalized np.atleast_1d, np.atleast_2d, np.atleast_3d with a<br>
> function np.atleast_nd in PR#7804<br>
> (<a href="https://github.com/numpy/numpy/pull/7804" target="_blank">https://github.com/numpy/numpy/pull/7804</a>).<br>
><br>
> As a result of this PR, I have a couple of questions about<br>
> `np.atleast_3d`. `np.atleast_3d` appears to do something weird with<br>
> the dimensions: If the input is 1D, it prepends and appends a size-1<br>
> dimension. If the input is 2D, it appends a size-1 dimension. This is<br>
> inconsistent with `np.atleast_2d`, which always prepends (as does<br>
> `np.atleast_nd`).<br>
><br>
>   - Is there any reason for this behavior?<br>
>   - Can it be cleaned up (e.g., by reimplementing `np.atleast_3d` in<br>
> terms of `np.atleast_nd`, which is actually much simpler)? This would<br>
> be a slight API change since the output would not be exactly the same.</p>
</span><p dir="ltr">Changing atleast_3d seems likely to break a bunch of stuff...</p>
<p dir="ltr">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.)</p>
<p dir="ltr">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?</p>
<p dir="ltr">Or maybe they're totally useful and I'm just missing it. What's your use case that motivates atleast_nd?</p><span class="HOEnZb"><font color="#888888"></font></span>
</blockquote></div>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.<br><br></div><div class="gmail_extra">For 3D/nD I can see that you'd need more control over where the dimensions go, but 1D/2D are fine.<br><br></div><div class="gmail_extra">Ralf<br><br></div></div>