[Python-ideas] Float range class
chris.barker at noaa.gov
Thu Jan 8 20:14:04 CET 2015
On Thu, Jan 8, 2015 at 9:58 AM, Todd <toddrjen at gmail.com> wrote:
> How does using numpy floats instead of python floats affect performance,
>> unless "it's too fast" or "it uses too little memory" are problems?
> 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.
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.
I think the real use case here is for code that is not using numpy at all.
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,
>> wouldn't a single duck-typed range cover all the bases, though perhaps
with less than optimum performance?
By the way, numpy's range works with virtually all types, including
In : np.arange(np.datetime64('2014-01-01'), np.datetime64('2014-01-10'))
array(['2014-01-01', '2014-01-02', '2014-01-03', '2014-01-04',
'2014-01-05', '2014-01-06', '2014-01-07', '2014-01-08',
Christopher Barker, Ph.D.
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chris.Barker at noaa.gov
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-ideas