On Wed, Nov 14, 2018 at 8:57 AM Stephan Hoyer wrote:

...

It recently came up on GitHub (at part of the discussion in

https://github.com/numpy/numpy/issues/12379) that numpy.linspace could, at least in principle, be modified to support array inputs:

...

It looks like this has been requested on StackOverflow, too:

https://stackoverflow.com/questions/46694167/vectorized-numpy-linspace-acros...

...

My tentative proposal: - "start" and "stop" are broadcast against each other to form start/stop

arrays. (Or we could require that start/stop have matching shape.)

...

- A new dimension of size "num" is inserted into the result, either along the first or last axis. - A new keyword argument "axis" could control where the axis is inserted in the result. - Vectorization support should be added in the same way to geomspace and logspace.

Does this seem like a good idea? It's a relatively simple generalization, and one that I, at least, would find useful (I can think of a use-case in my own code that came up just last week).

This feels a bit forced. There's not much relevance to the minor

I put in an issue a while ago, https://github.com/numpy/numpy/issues/8839 My use case was somwhat similar to meshgrid but with a nonrectangular domain. Not terribly hard to code, but my expectation is that numpy functions should always allow broadcasting if that operation makes sense. On Nov 14, 2018 12:42 PM, "Gerrit Holl" wrote: On Wed, 14 Nov 2018 at 17:29, Ralf Gommers wrote: performance gain, and for code clarity it probably also wouldn't help (actually it hurts usability for 99.x% of use cases by making the doc more complicated). Not sure that it really would require a new axis argument, as Marten said on the issue. Also, the num keyword cannot be vectorized, unless one returns a list of arrays, which would actually be more natural here than a 2-D array.

So, at best a don't care for me - I'm -0.5.

For what it's worth, I had a use case for this in the past week, when I needed many simple linear interpolations between two values (thus a linspace) with only the value of boundary points varying. However, this was the first time I've ever needed it, and I found a recipe on Stack Overflow within minutes (https://stackoverflow.com/a/42617889/974555) so it wasn't a big deal that it wasn't available in core numpy. Gerrit. _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion

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. I think this used to half work at some point, but it was probably so broken that we can just make it well defined? - Sebastian

-- Marten _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion

On Wed, 2018-11-14 at 14:46 -0800, Stephan Hoyer wrote:

On Wed, Nov 14, 2018 at 2:35 PM Sebastian Berg < sebastian@sipsolutions.net> wrote:

...

On Wed, 2018-11-14 at 14:32 -0500, Marten van Kerkwijk wrote:

<snip>

...

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 think that argument goes both ways. Because linspace with an array input can be seen as stacking the linear ramps and not stacking some interpolated intermediate values from start/stop. (Sure, it is more then one dimension, but I would seriously argue the linear ramps are the basic building block and not the input start/stop arrays.) - Sebastian

_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion