<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Jan 8, 2015 at 6:41 PM, Andrew Barnert <span dir="ltr"><<a href="mailto:abarnert@yahoo.com" target="_blank">abarnert@yahoo.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><span class=""><div>On Jan 8, 2015, at 8:01, Todd <<a href="mailto:toddrjen@gmail.com" target="_blank">toddrjen@gmail.com</a>> wrote:</div><blockquote type="cite"><div dir="ltr"><div><div><div><div><div><p dir="ltr">The current approaches for float ranges all have significant limitations.  numpy.arange pre-allocates the values and doesn't use python floats, both of which affect performance.  </p></div></div></div></div></div></div></blockquote></span><div>How does using numpy floats instead of python floats affect performance, unless "it's too fast" or "it uses too little memory" are problems?</div></div></blockquote><div><br><br></div><div>If you are using numpy arrays with numpy functions, it isn't an issue.  But if you are using it in a similar manner to the existing range class, at some point it is likely going to interact with python native types (such as adding a numpy scalar to a python float).  This require a type conversion, either python float to numpy scalar or vice versus, and that is relatively slow.  I have profiled it, this can be the primary bottleneck in numerical code that can't be vectorized for whatever reason.<br></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"><span class=""><blockquote type="cite"><div dir="ltr"><div><div><div><div><div><p dir="ltr">The third approach is to create a new module for various range classes.  For example there could be a float range, a datetime range, a decimal range, a duck-typed range, an abstract base class for making new range classes, etc.  However, this is a lot more work (although it wouldn't need to all be done at one time).</p></div></div></div></div></div></div></blockquote></span><div>I think what you'd really want is a full suite of interval/count/range APIs over various types. For example, a datetime range that doesn't even allow offsetting or comparing for overlap doesn't seem all that useful. I can think of lots of uses for all kinds of range-like things, but none of them are well satisfied by just a range view that acts like a sequence and has no other methods, short of iterating them (for which a generator expression is sufficient--or, if you're doing a lot of them in some app for some reason, a one-liner function that wraps up the genexpr).</div><div><br></div></div></blockquote><div><br></div><div>The capabilities of the classes in the module would need to be discussed if there was actually a desire for such a module.  I personally only commonly see float ranges, so I limited the discussion mostly to those.  However, I wanted to be as comprehensive as possible about the options, so provided some rough examples of the sorts of things that could potentially appear in such a module.  Since I don't really have a use for the additional classes I don't really know what their specific needs would be.<br></div><div> </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>More generally: if an frange that works exactly like range but with floats (and rounding errors) is all you want, that's so trivial to write that it doesn't seem worth putting in the stdlib, unless the use case is very common. </div></div></blockquote><div><br></div><div>In numerical computing the use-case is extremely common, in fact I would say it practically universal.  Ideally it would be vectorized, but in practice this is often not possible, requiring the use of loops.<br></div></div></div></div>