[Python-ideas] Float range class
Neil Girdhar
mistersheik at gmail.com
Fri Jan 9 04:01:55 CET 2015
I agree with everyone above. At first I was +1 on this proposal, but why
not suggest to the numpy people that arange and linespace should return
Sequence objects rather than numpy arrays? I'm pretty sure there's a way
to make sure objects work in numpy.
Also, didn't realize you could do this:
In [9]: np.linspace(0, 10, 4, dtype=np.int)
Out[9]: array([ 0, 3, 6, 10])
Kind of cool to have that for the integers. Too bad it's an array and not
a Sequence object.
Best,
Neil
On Thursday, January 8, 2015 at 5:37:09 PM UTC-5, Chris Barker wrote:
>
> On Thu, Jan 8, 2015 at 1:33 PM, Andrew Barnert <abar... at yahoo.com
> <javascript:>> wrote:
>
>
>> Implementing it badly isn't much of a problem; even if you don't
>> precompute the stop, you're just adding the cost of a multiplication to
>> every __getitem__, and I doubt that's going to be a bottleneck in most
>> applications.
>>
>
> I wasn't talking about performance, I was talking about the vagaries of
> floating point. for example, an obvious (easy, anyway) thing to do is
> somethign like:
>
> val = start
> while val < stop:
> val += step
>
> but that's not a great idea with fp.
>
>
>> It's _using_ it badly that's the more serious problem. Just as with
>> np.arange, a naive use of frange will lead to rounding problems, and I
>> can't see how a builtin could provide any API that avoids that problem…
>>
>
> which is why I'm suggesting that a built in be more like numpy's linspace
> than like range. See Warren's note for a better explanation with examples.
>
> Another of my points is that while ranges of floating point numbers are
> very commonly used, the use cases are generally quite different than for
> ranges of integers, so we may not want the same API, floating point issues
> aside. The most common cases for range are:
>
> a) Give me n numbers
>
> b) Loop n times
>
> c) Give me all the indexes for a sequence of length n
>
> d) Give me all the numbers from a to b
> - then you need to think about whether you are including b or not, and
> add 1 if you want it.
>
> e) Give me every j-th number from a to b.
> - then you need to think even more about the end point (if you care)
>
> Note that you need to think about the last value in (d) and (e), but
> that's pretty easy to do, and not prone to error with integers.
>
> But for floating point range-like things:
>
> a -- c are not relevant.
>
> d) is more likely to be spelled as: Give me n numbers evenly spaced from a
> to b -- that's np.linspace()
>
> e) is essentially: give me all the numbers form a to be, using this delta.
> - this seems like a floating point range, but again, you need to think
> carefully about the end points, so you're really better off with llnspace,
> and then once the end points have been defined, you can write FP code that
> will do the expected thing.
>
> -Chris
>
> --
>
> 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.... at noaa.gov <javascript:>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150108/09a2048f/attachment.html>
More information about the Python-ideas
mailing list