<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">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 class=""><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><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 class=""><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><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><div><br></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 class=""><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><div>wouldn't a single duck-typed range cover all the bases, though perhaps with less than optimum performance?</div><div><br></div><div>By the way, numpy's range works with virtually all types, including datetime64:</div><div><br></div><div><div><div>In [21]: np.arange(np.datetime64('2014-01-01'), np.datetime64('2014-01-10'))</div><div><br></div><div>Out[21]:</div><div> </div><div>array(['2014-01-01', '2014-01-02', '2014-01-03', '2014-01-04',</div><div> '2014-01-05', '2014-01-06', '2014-01-07', '2014-01-08', '2014-01-09'], dtype='datetime64[D]')</div></div></div></div><div><br></div><div>-Chris</div><div><br></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>