[Python-ideas] Float range class

[Nathaniel Smith]

On 9 Jan 2015 10:21, "Todd" <toddrjen at gmail.com> wrote:
>
> On Thu, Jan 8, 2015 at 7:40 PM, Nathaniel Smith <njs at pobox.com> wrote:
>>
>> On Thu, Jan 8, 2015 at 5:58 PM, Todd <toddrjen at gmail.com> wrote:
>> > On Thu, Jan 8, 2015 at 6:41 PM, Andrew Barnert <abarnert at yahoo.com>
wrote:
>> >>
>> >> 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.
>>
>> Can you give a more specific example? I believe your problem is real,
>> but as a numerical programmer I can't think of an example of where
>> I've ever wanted anything like this, so it's hard for me to visualize
>> what exactly you're talking about.
>
>
> Here is one right from the scipy cookbook:
> http://wiki.scipy.org/Cookbook/Theoretical_Ecology/Hastings_and_Powell
> But in practice, it would be any case where a range of values are needed,
and you can't vectorize for whatever reason (such as having mutable values,
needing to do things out of order, or relying on some arbitrary data set).

Perhaps I'm being dense, but I can't see how a lazy frange object would
help the linked-to code? The only place I can see that looks relevant is
where it does enumerate (np.linspace(...)). But AFAICT this neither
requires range semantics nor lazy view machinery, which I thought were the
two main things you're arguing for.

It's also very unlikely that materializing the linspace array here is
anywhere close to being a bottleneck. (It calls odeint on every iteration!)
So it's a theoretical inefficiency, but we have to accept a lot of those if
we want to program in python, and focus our efforts on the ones that really
matter.

> Some other examples:
> 1. Anything done in parallel on a range of values (here is an example,
although they don't give the actual algorithm
http://stackoverflow.com/questions/11210677/need-help-to-parallelize-a-loop-in-python
)

This example also seems to just be iterating over the return value from
linspace, and performing very slow computations for each entry? So same
comments as above.

> 2. Using individual floats as inputs to another program or library (I am
doing this right now for simulation, I only use numpy because it is the
only easy way to get the ranges I need)

This sounds similar to the previous two cases too.

> 3. Many types a stair step adaptive approaches in experiments (
http://en.wikipedia.org/wiki/Psychophysics#Staircase_procedures)

I've never implemented one of these so I can't really comment, but in this
case don't you have to get input from a human on every pass through the
loop? Hardly a case where the numpy overhead is going to be crucial, right?

Again, I'm not trying to nitpick your examples, I'm just trying to get a
concrete idea of what parts of your proposal provide what benefits.

-n
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150109/efcc5cd9/attachment-0001.html>