proposal: new logspace without the log in the argument
I've suggested a new function similar to logspace, but where you specify the start and stop points directly instead of using log(start) and base arguments: https://github.com/numpy/numpy/issues/7255 https://github.com/numpy/numpy/pull/7268
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 Wed, Feb 17, 2016 at 4:35 PM, . <nr4qewd6v4@snkmail.com> wrote:
I've suggested a new function similar to logspace, but where you specify the start and stop points directly instead of using log(start) and base arguments:
https://github.com/numpy/numpy/issues/7255 https://github.com/numpy/numpy/pull/7268 _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
-- Nathaniel J. Smith -- https://vorpus.org
On Thu, Feb 18, 2016 at 7:38 PM, Nathaniel Smith <njs@pobox.com> 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 alternative interface might be something like
np.linspace(start, stop, steps, spacing="log")
what do people think?
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. -- Robert Kern
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 <robert.kern@gmail.com> wrote:
On Thu, Feb 18, 2016 at 7:38 PM, Nathaniel Smith <njs@pobox.com> 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 alternative interface might be something like
np.linspace(start, stop, steps, spacing="log")
what do people think?
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.
-- Robert Kern
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
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 a new function correct the apparent mistake (?) of `linspace` including the endpoint by default? Or is the current API justified by its Matlab origins? (Or have I missed the point altogether?) If this query is annoying, please ignore it. It is not meant to be. Alan
On Thu, Feb 18, 2016 at 10:19 PM, Alan Isaac <alan.isaac@gmail.com> 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 violate the van Rossum Rule of Function Signatures.
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? (Or have I missed the point altogether?)
The last, I'm afraid. Different use cases, different conventions. Integer ranges are half-open because that is the most useful convention in a 0-indexed ecosystem. Floating point ranges don't interface with indexing, and the closed intervals are the most useful (or at least the most common).
If this query is annoying, please ignore it. It is not meant to be.
The same for my answer. -- Robert Kern
On Thu, Feb 18, 2016 at 2:19 PM, Alan Isaac <alan.isaac@gmail.com> 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 including the endpoint in the sequence -- for the common use cases, it's often what you want, and if it didn't include the end point but you did want that, it would get pretty ugly to figure out how to get what you want. On the other hand, if I had it to do over, I would have the count specify the number of intervals, rather than the number of items. A common cae may be: values from zero to 10 (inclusive), and I want ten steps: In [19]: np.linspace(0, 10, 10) Out[19]: array([ 0. , 1.11111111, 2.22222222, 3.33333333, 4.44444444, 5.55555556, 6.66666667, 7.77777778, 8.88888889, 10. ]) HUH? I was expecting [0,1,2,3 ....] (OK, not me, this isn't my first Rodeo), so now I need to do: In [20]: np.linspace(0, 10, 11) Out[20]: array([ 0., 1., 2., 3., 4., 5., 6., 7., 8., 9., 10.]) This gets uglier if I know what "delta" I want: In [21]: start = 0.0; end = 9.0; delta = 1.0 In [24]: np.linspace(start, end, (end-start)/delta) Out[24]: array([ 0. , 1.125, 2.25 , 3.375, 4.5 , 5.625, 6.75 , 7.875, 9. ]) oops! In [25]: np.linspace(start, end, (end-start)/delta + 1) Out[25]: array([ 0., 1., 2., 3., 4., 5., 6., 7., 8., 9.]) But in any case, there is no changing it now. -CHB -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov
participants (6)
-
. -
Alan Isaac -
Chris Barker -
Joseph Fox-Rabinovitz -
Nathaniel Smith -
Robert Kern