[Python-ideas] Float range class

[Andrew Barnert]

On Jan 8, 2015, at 11:05, Chris Barker <chris.barker at noaa.gov> wrote:

>> I would think that a floating range class would necessarily use multiplication rather than repeated addition (to allow indexing at arbitrary point), which would avoid cumulative floating-point errors (although it would still have a smaller floating point error at the end), and for the same reason the final value would have to be pre-computed rather than using a naive ">=" which would allow it to be a bit smarter.
> 
> That's the trick -- range() (and arange) does not specify a final value, it specifies a final value not to include. This is well defined and easy to understand for integers, but not so for floating point. But you are right about the multiplication and pre-computing of final value -- that's a good reason to provide this as a built-in -- it's very easy to implement, but even easier to implement badly.

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. 

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…

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150108/cfe43b1a/attachment.html>