<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 8, 2015 at 8:14 PM, Chris Barker <span dir="ltr"><<a href="mailto:chris.barker@noaa.gov" target="_blank">chris.barker@noaa.gov</a>></span> wrote:<br><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>On Thu, Jan 8, 2015 at 9:58 AM, Todd <span dir="ltr"><<a href="mailto:toddrjen@gmail.com" target="_blank">toddrjen@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="auto"><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></div></span></div></div></div></blockquote></span><div>... </div><span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><div></div></span><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></div></div></blockquote><div><br></div></span><div>Sure, but this is a core issue with numpy, period. There are, in fact, some things that work faster with python native data types than numpy. But if you are interacting with numpy arrays, it's hard for me to imagine that this one bottleneck is going to be key.</div><div><br></div><div>I think the real use case here is for code that is not using numpy at all.</div><span><div><br></div></span></div></div></div></blockquote><div><br></div><div>Exactly.  This is a case where people use numpy just because it is the only commonly-used package that provides any sort of floating-point range, and their performance can suffer considerably because of it.  I have had cases where I use numpy.linspace or numpy.arange and then convert it to python types up-front because the values are re-used many times in loops and this hurts performance.  That is why I am suggesting having one that doesn't use numpy ranges.<br></div><div> </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><div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="auto"><span><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, </p></div></div></div></div></div></div></blockquote></span></div></blockquote></span></div></div></div></blockquote></span><div>wouldn't a single duck-typed range cover all the bases, though perhaps with less than optimum performance?<br><br></div></div></div></div></blockquote><div><br></div><div>If all the ranges behaved exactly the same, yes.  But there might be special corner cases for particular range types that might require optional arguments or something.  And having optimized versions may very well be an important enough issue on its own.<br><br></div><div>Overall, though, I was just trying to make sure all alternative approaches I could think of were mentioned.  There might be additional issues with the various approaches I wasn't aware of, so I thought they should all be mentioned.<br></div></div></div></div>