[Python-ideas] Float range class

[Andrew Barnert]

On Jan 9, 2015, at 23:03, Andrew Barnert <abarnert at yahoo.com.dmarc.invalid> wrote:

> On Jan 9, 2015, at 21:13, Guido van Rossum <guido at python.org> wrote:
> 
>> - numeric tricks to avoid intermediate overflows or numeric instabilities, plus optimizations
> 
> I'll leave this to others. (If no one steps up, I can look at the numpy code, but I'm sure this list has people who know it off the top of their heads.)

Actually, here's what numpy does:

    step = (stop-start)/float((num-1))
    y = arange(0, num) * step + start
    y[-1] = stop

De-vectorize that, and it's exactly your too-naive algorithm (except for the off-by-1), with a simple fix for inexact stop.

From a quick check, the timing is almost identical (6.89us vs. 6.49us to enumerate linspace(1, 2, 5000). 

It doesn't _normally_ accumulate rounding errors. For example, whether I use the same test, or much smaller numbers, every 5th element, and sometimes the one immediately after, is off by one digit, but the intervening elements are identical. However, if you get down to denormal values, then the underflow _does_ accumulate. For example, linspace(0, 2e-323, 10) should give (0, 0, 5e-324, 5e-324. ...), and the smart version does that, but the naive version--and numpy--gives all 0s. And if you build a simple 4.2 fixed-point type and ask for linspace(0, .1, 100), again you get all 0s. On the other hand, the naive version avoids overflow problems at the other end of the scale, so maybe that's a wash?

And, since you no longer need to multiply start or stop by an integer, only stop-start, it works for types like datetime.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150110/24d13190/attachment.html>