[Python-ideas] Float range class

Todd toddrjen at gmail.com
Fri Jan 9 11:27:17 CET 2015


On Thu, Jan 8, 2015 at 8:14 PM, Chris Barker <chris.barker at noaa.gov> wrote:

> 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.
>
>
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.


> 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?
>
>
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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150109/429b749e/attachment-0001.html>


More information about the Python-ideas mailing list