Re: [Numpy-discussion] proposal: new logspace without the log in the argument

2016-02-18 Thread Peter Creasey
> > Some questions it'd be good to get feedback on: > > - any better ideas for naming it than "geomspace"? It's really too bad > that the 'logspace' name is already taken. > > - I guess the alternative interface might be something like > > np.linspace(start, stop, steps, spacing="log") > > what do

Re: [Numpy-discussion] Suggestion: special-case np.array(range(...)) to be faster

2016-02-18 Thread Antony Lee
In a sense this discussion is really about making np.array(iterable) more efficient, so I restarted the discussion at https://mail.scipy.org/pipermail/numpy-discussion/2016-February/075059.html Antony 2016-02-18 14:21 GMT-08:00 Chris Barker : > On Thu, Feb 18, 2016 at

Re: [Numpy-discussion] proposal: new logspace without the log in the argument

2016-02-18 Thread Chris Barker
On Thu, Feb 18, 2016 at 2:19 PM, Alan Isaac wrote: > Would such a new function correct the apparent mistake (?) of > `linspace` including the endpoint by default? > Or is the current API justified by its Matlab origins? > I don't think so -- we don't need no stinkin'

Re: [Numpy-discussion] proposal: new logspace without the log in the argument

2016-02-18 Thread Robert Kern
On Thu, Feb 18, 2016 at 10:19 PM, Alan Isaac wrote: > > On 2/18/2016 2:44 PM, Robert Kern wrote: >> >> In a new function not named `linspace()`, I think that might be fine. I do occasionally want to swap between linear and logarithmic/geometric spacing based on a parameter,

Re: [Numpy-discussion] Suggestion: special-case np.array(range(...)) to be faster

2016-02-18 Thread Chris Barker
On Thu, Feb 18, 2016 at 10:15 AM, Antony Lee wrote: > Mostly so that there is no performance lost when someone passes range(...) > instead of np.arange(...). At least I had never realized that one is much > faster than the other and always just passed range() as a

Re: [Numpy-discussion] proposal: new logspace without the log in the argument

2016-02-18 Thread Alan Isaac
On 2/18/2016 2:44 PM, Robert Kern wrote: In a new function not named `linspace()`, I think that might be fine. I do occasionally want to swap between linear and logarithmic/geometric spacing based on a parameter, so this doesn't violate the van Rossum Rule of Function Signatures. Would such

Re: [Numpy-discussion] proposal: new logspace without the log in the argument

2016-02-18 Thread Joseph Fox-Rabinovitz
I like the idea, as long as we all remain aware of the irony of having a "log" spacing for a function named "lin"space. -Joe On Thu, Feb 18, 2016 at 2:44 PM, Robert Kern wrote: > On Thu, Feb 18, 2016 at 7:38 PM, Nathaniel Smith wrote: >> >> Some

Re: [Numpy-discussion] proposal: new logspace without the log in the argument

2016-02-18 Thread Robert Kern
On Thu, Feb 18, 2016 at 7:38 PM, Nathaniel Smith wrote: > > Some questions it'd be good to get feedback on: > > - any better ideas for naming it than "geomspace"? It's really too bad > that the 'logspace' name is already taken. geomspace() is a perfectly cromulent name, IMO. > -

Re: [Numpy-discussion] proposal: new logspace without the log in the argument

2016-02-18 Thread Nathaniel Smith
Some questions it'd be good to get feedback on: - any better ideas for naming it than "geomspace"? It's really too bad that the 'logspace' name is already taken. - I guess the alternative interface might be something like np.linspace(start, stop, steps, spacing="log") what do people think? -n

Re: [Numpy-discussion] Suggestion: special-case np.array(range(...)) to be faster

2016-02-18 Thread josef.pktd
On Thu, Feb 18, 2016 at 1:15 PM, Antony Lee wrote: > Mostly so that there is no performance lost when someone passes range(...) > instead of np.arange(...). At least I had never realized that one is much > faster than the other and always just passed range() as a

Re: [Numpy-discussion] Suggestion: special-case np.array(range(...)) to be faster

2016-02-18 Thread Antony Lee
Mostly so that there is no performance lost when someone passes range(...) instead of np.arange(...). At least I had never realized that one is much faster than the other and always just passed range() as a convenience. Antony 2016-02-17 10:50 GMT-08:00 Chris Barker : >

Re: [Numpy-discussion] FeatureRequest: support for array construction from iterators

2016-02-18 Thread Antony Lee
Actually, while working on https://github.com/numpy/numpy/issues/7264 I realized that the memory efficiency (one-pass) argument is simply incorrect: import numpy as np class A: def __getitem__(self, i): print("A get item", i) return [np.int8(1), np.int8(2)][i] def