
<html xmlns="http://www.w3.org/1999/xhtml"><head> <title></title> <meta name="viewport" content="width=device-width, initial-scale=1.0, user-scalable=no"> </head> <body style="font-family:Helvetica;color:#000000;font-size:13px;"> <div id="CanaryDropbox"> </div> <blockquote id="CanaryBlockquote"> <div> <div>On Wednesday, Nov 14, 2018 at 11:46 PM, Stephan Hoyer <<a href="mailto:shoyer@gmail.com">shoyer@gmail.com</a>> wrote:<br></div> <div><div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Wed, Nov 14, 2018 at 2:35 PM Sebastian Berg <<a href="mailto:sebastian@sipsolutions.net">sebastian@sipsolutions.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Wed, 2018-11-14 at 14:32 -0500, Marten van Kerkwijk wrote:<br> > Code being better than words: see <br> > <a href="https://github.com/numpy/numpy/pull/12388" rel="noreferrer" target="_blank">https://github.com/numpy/numpy/pull/12388</a> for an implementation. The<br> > change in the code proper is very small, though it is worrying that<br> > it causes two rather unrelated tests too fail (even if arguably both<br> > tests were wrong).<br> > <br> > Note that this does not give flexibility to put the axis where one<br> > wants; as written, the code made putting it at the start the obvious<br> > solution, as it avoids doing anything with the shapes of start and<br> > stop.<br> <br> Hehe, my first gut feeling was the last axis to be the obvious one ;).<br> This has been discussed before (but what hasn't) I believe, probably<br> some old issue or even PR somewhere.<br> I am mildly in favor, just because there is probably not much reason<br> against an easy vectorization. Doesn't need to be advertised much in<br> the docs anyway.<br> Although it might be good to settle the "obvious" part in case I am not<br> alone in first thinking of -1 being the obvious default. I would<br> probably skip the axis argument for now, unless someone actually has a<br> use case.</blockquote><div><br></div><div>Indeed -- I think the best argument for adding an "axis" argument is that it allows people to be explicit about where the axis ends up, e.g., both np.linspace(start, stop, num=5, axis=0) and np.linspace(start, stop, num=5, axis=-1) make their intent quite clear.</div><div><br></div><div>To me, axis=0 feels like the right default, matching np.concatenate and np.stack. But NumPy already has split conventions for this sort of thing (e.g., gufuncs add axes at the end), so I like the explicit option.</div></div></div></div></div></blockquote><div id="CanaryBody"><div><br></div><div>I’d like to have another vote for axis=-1 by default. Stack and concatenate are different because we are concatenating/stacking complete arrays, so it makes sense to “compose” them along the first axis to maintain C-contiguous-ness.</div><div><br></div><div>I actually think of this as the reverse, we are “composing/combining” lots of 1D arrays over all the other dimensions, so to preserve C-contiguous-ness, it’s better to have axis=-1.</div><div><br></div></div><blockquote><div><div> _______________________________________________ <br>NumPy-Discussion mailing list <br>NumPy-Discussion@python.org <br>https://mail.python.org/mailman/listinfo/numpy-discussion <br></div></div></blockquote><br> <div><div>Best Regards,<div>Hameer Abbasi</div></div></div><img id="0C295C0CB0EC97731DBF5A4AEFDFEC4E" width="1px" src="http://pixels.canarymail.io:8100/track/977C99C0645380AF45E168B4CDA443F5_0C295C0CB0EC97731DBF5A4AEFDFEC4E.png" height="1px"></body></html>