<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>On Jan 8, 2015, at 14:35, Chris Barker <<a href="mailto:chris.barker@noaa.gov">chris.barker@noaa.gov</a>> wrote:</div><div><br></div><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Jan 8, 2015 at 1:33 PM, Andrew Barnert <span dir="ltr"><<a href="mailto:abarnert@yahoo.com" target="_blank">abarnert@yahoo.com</a>></span> wrote:<br><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><span class=""><div>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. </div></span></div></blockquote><div><br></div><div>I wasn't talking about performance, I was talking about the vagaries of floating point. </div></div></div></div></div></blockquote><div><br></div><div>I think you may be disagreeing with the wrong person here (Todd is the one who proposed this feature; I was pointing out problems with it), but just in case you actually meant that a properly-implemented frange actually _could_ solve problems with floating-point vagaries:</div><br><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>for example, an obvious (easy, anyway) thing to do is somethign like:</div><div><br></div><div>val = start</div><div>while val < stop:</div><div> val += step</div><div><br></div><div>but that's not a great idea with fp.</div></div></div></div></div></blockquote><div><br></div><div>But this is just as bad an idea--and it's presumably exactly equivalent to what frange would do:</div><div><br></div><div> for i in count():</div><div> val = start + i*step</div><div> if val >= stop: break</div><div><br></div><div>For example, try it with start=0, step=0.3, stop=0.9, and you'll get 0, 0.3. 0.6, and 0.8999999999999999--exactly the same (probably-)incorrect result you get from repeated addition.</div><div><br></div><div>In other words, as I said, the problem isn't that it's difficult to implement correctly; the problem is that it's difficult to _use_ correctly. Which, to me, seems like an argument against it being in the stdlib, not for it.</div><div><br></div><blockquote type="cite"><div><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="auto"><div></div><div>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…</div></div></blockquote><div><br></div><div>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.</div></div></div></div></div></blockquote><div><br></div><div>Sure; I said effectively the same thing. That's why I mentioned that arange has the same problem. A float linspace view might be useful; a float range view is an attractive nuisance. So I think we agree?</div></body></html>