[Python-ideas] Float range class

[Todd]

On Thu, Jan 8, 2015 at 6:41 PM, Andrew Barnert <abarnert at yahoo.com> wrote:

> On Jan 8, 2015, at 8:01, Todd <toddrjen at gmail.com> wrote:
>
> 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.
>
> 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.

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


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

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