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 wrote:
> On Wed, Nov
On Wed, Nov 14, 2018 at 3:16 PM Marten van Kerkwijk <
m.h.vankerkw...@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.
> --
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
___
NumPy-Discussion mailing list
> On Wednesday, Nov 14, 2018 at 11:46 PM, Stephan Hoyer (mailto:sho...@gmail.com)> wrote:
>
>
> On Wed, Nov 14, 2018 at 2:35 PM Sebastian Berg (mailto:sebast...@sipsolutions.net)> wrote:
> > On Wed, 2018-11-14 at 14:32 -0500, Marten van Kerkwijk wrote:
> > > Code being better than words: see
>
On Wed, Nov 14, 2018 at 2:35 PM Sebastian Berg
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
On Wed, Nov 14, 2018 at 1:21 PM Lars Grüter wrote:
>
> This reminds me of a function [1] I wrote which I think has a lot of
> similarities to what Stephan describes here. It is currently part of a
> PR to rewrite numpy.pad [2].
>
> If we start to write the equivalent internally, then perhaps we
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
On 14.11.18 17:57, 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,
Just to add: nothing conceptually is strange for start and end to be
arrays. Indeed, the code would work for arrays as is if it didn't check the
`step == 0` case to handle denormals (arguably an even less common case
than array-like inputs...), and made a trivial change to get the new axis
to be
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
On Wed, 14 Nov 2018 at 17:29, Ralf Gommers wrote:
> 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
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
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:
13 matches
Mail list logo
