Vectorized version of numpy.linspace
On Wednesday, Nov 14, 2018 at 11:46 PM, Stephan Hoyer <shoyer@gmail.com (mailto:shoyer@gmail.com)> wrote:
On Wed, Nov 14, 2018 at 2:35 PM Sebastian Berg <sebastian@sipsolutions.net (mailto:sebastian@sipsolutions.net)> wrote:
On Wed, 2018-11-14 at 14:32 -0500, Marten van Kerkwijk wrote:
Code being better than words: see https://github.com/numpy/numpy/pull/12388 for an implementation. The change in the code proper is very small, though it is worrying that it causes two rather unrelated tests too fail (even if arguably both tests were wrong).
Note that this does not give flexibility to put the axis where one wants; as written, the code made putting it at the start the obvious solution, as it avoids doing anything with the shapes of start and stop.
Hehe, my first gut feeling was the last axis to be the obvious one ;). This has been discussed before (but what hasn't) I believe, probably some old issue or even PR somewhere. I am mildly in favor, just because there is probably not much reason against an easy vectorization. Doesn't need to be advertised much in the docs anyway. Although it might be good to settle the "obvious" part in case I am not alone in first thinking of -1 being the obvious default. I would probably skip the axis argument for now, unless someone actually has a use case.
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.
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.
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. 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.
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
Best Regards, Hameer Abbasi
I see the logic in having the linear space be last, but one non-negligible advantage of the default being the first axis is that whatever is produced broadcasts properly against start and stop. -- Marten
On Wed, Nov 14, 2018 at 3:16 PM Marten van Kerkwijk < m.h.vankerkwijk@gmail.com> wrote:
I see the logic in having the linear space be last, but one non-negligible advantage of the default being the first axis is that whatever is produced broadcasts properly against start and stop. -- Marten
Yes, this is exactly why I needed to insert the new axis at the start. That said, either default axis position is fine by me as long as we have the explicit option.
I too buy into axis=0 being the better default here for broadcasting reasons. Having it possible to specify explicitly would be handy though, for something like: x_ramped = np.linspace(x.min(axis=2), x.max(axis=2), 100, axis=2) On Wed, 14 Nov 2018 at 15:20 Stephan Hoyer <shoyer@gmail.com> wrote:
On Wed, Nov 14, 2018 at 3:16 PM Marten van Kerkwijk < m.h.vankerkwijk@gmail.com> wrote:
I see the logic in having the linear space be last, but one non-negligible advantage of the default being the first axis is that whatever is produced broadcasts properly against start and stop. -- Marten
Yes, this is exactly why I needed to insert the new axis at the start.
That said, either default axis position is fine by me as long as we have the explicit option. _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
participants (4)
-
Eric Wieser -
Hameer Abbasi -
Marten van Kerkwijk -
Stephan Hoyer