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 __len__(
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 :
> On Sun, Feb 14, 2016 at
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 convenience.
>
> Antony
>
> 2016
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
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.
> - I guess the alte
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 questions it'd be good to get feedback on:
>>
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
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 convenience.
>
Well, pretty m
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, so this
>> doesn't viol
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' Matlab !
But I LIKE includi
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 10:15 AM, Antony Lee
> wro
>
> 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
12 matches
Mail list logo
