<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>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.<br></div></div></div></div></blockquote><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> But, at least in my own experience, I use arange when I want an interval-based range, and linspace when I want a count-based range.</div></div></div></div></blockquote></span></div></div></div></blockquote><div><br></div><div>I would argue (and do!) that you should not do this -- if you know what you are doing with FP, then fine, but it really is tricky. You would be better off computing the count you want then then using linspace anyway. I suppose an interval-based API to something like linspace would be a nice convenience, though.</div><div><br></div><div>I haven't managed to come up with a quick an easy example where this matters, but they DO happen.</div><div><br></div><div>I guess I'm arguing that a range-like object for FP should be a closed rather than open interval -- specifying the starting and end points. That is because defining an open interval where numbers are of finite, but hard to know know in advance the interval, is just too ugly and complex.</div><div><br></div><div>I see your point that sometimes you want a specific delta, and sometimes you want a specific end point, but I supect that most of the time you want a specific delta you ALSO want a specific and point and/or want to know how many values you are going to get. </div><div><br></div><div>In fact, in the most common use of integer range, you really are defining the number of values you want.</div><div><br></div><div>And note that the range convention of starting at zero and not including the stop value was designed to match python indexing convention, i.e.:</div><div><br></div><div>for i in range( len(sequence) ):</div><div>    ...</div><div><br></div><div>is natural an easy to write, and does what's expected. And also:</div><div><br></div><div>for i in range(n):</div><div>    ....</div><div><br></div><div>will loop n times.</div><div><br></div><div>but neither of these apply to floating point ranges.</div><div><br></div><div>-Chris</div><div><br></div></div>-- <br><div class="gmail_signature"><br>Christopher Barker, Ph.D.<br>Oceanographer<br><br>Emergency Response Division<br>NOAA/NOS/OR&R            (206) 526-6959   voice<br>7600 Sand Point Way NE   (206) 526-6329   fax<br>Seattle, WA  98115       (206) 526-6317   main reception<br><br><a href="mailto:Chris.Barker@noaa.gov" target="_blank">Chris.Barker@noaa.gov</a></div>
</div></div>