<div dir="ltr">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.<div><br></div><div>Also, didn't realize you could do this:</div><div><br></div><div><div>In [9]: np.linspace(0, 10, 4, dtype=np.int)</div><div>Out[9]: array([ 0, 3, 6, 10])</div><div><br></div><div>Kind of cool to have that for the integers. Too bad it's an array and not a Sequence object.</div><div><br></div><div>Best,</div><div>Neil</div><div><div><div><br>On Thursday, January 8, 2015 at 5:37:09 PM UTC-5, Chris Barker wrote:<blockquote class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir="ltr"><div><div class="gmail_quote">On Thu, Jan 8, 2015 at 1:33 PM, Andrew Barnert <span dir="ltr"><<a href="javascript:" target="_blank" gdf-obfuscated-mailto="5aVHoTANTNoJ" onmousedown="this.href='javascript:';return true;" onclick="this.href='javascript:';return true;">abar...@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><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. 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> <br></div><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><br></div><div>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:</div><div><br></div><div>a) Give me n numbers</div><div><br></div><div>b) Loop n times</div><div><br></div><div>c) Give me all the indexes for a sequence of length n</div><div><br></div><div>d) Give me all the numbers from a to b</div><div> - then you need to think about whether you are including b or not, and add 1 if you want it.</div><div><br></div><div>e) Give me every j-th number from a to b.</div><div> - then you need to think even more about the end point (if you care)</div><div><br></div><div>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.</div><div><br></div><div>But for floating point range-like things:</div><div><br></div><div>a -- c are not relevant.</div><div><br></div><div>d) is more likely to be spelled as: Give me n numbers evenly spaced from a to b -- that's np.linspace()</div><div><br></div><div>e) is essentially: give me all the numbers form a to be, using this delta.</div><div> - 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.</div><div><br></div><div>-Chris</div><div><br></div></div>-- <br><div><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="javascript:" target="_blank" gdf-obfuscated-mailto="5aVHoTANTNoJ" onmousedown="this.href='javascript:';return true;" onclick="this.href='javascript:';return true;">Chris....@noaa.gov</a></div>
</div></div>
</blockquote></div></div></div></div></div>