[Python-ideas] Float range class

[Neil Girdhar]

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>