<p dir="ltr">On 9 Jan 2015 10:21, "Todd" <<a href="mailto:toddrjen@gmail.com">toddrjen@gmail.com</a>> wrote:<br>
><br>
> On Thu, Jan 8, 2015 at 7:40 PM, Nathaniel Smith <<a href="mailto:njs@pobox.com">njs@pobox.com</a>> wrote:<br>
>><br>
>> On Thu, Jan 8, 2015 at 5:58 PM, Todd <<a href="mailto:toddrjen@gmail.com">toddrjen@gmail.com</a>> wrote:<br>
>> > On Thu, Jan 8, 2015 at 6:41 PM, Andrew Barnert <<a href="mailto:abarnert@yahoo.com">abarnert@yahoo.com</a>> wrote:<br>
>> >><br>
>> >> More generally: if an frange that works exactly like range but with floats<br>
>> >> (and rounding errors) is all you want, that's so trivial to write that it<br>
>> >> doesn't seem worth putting in the stdlib, unless the use case is very<br>
>> >> common.<br>
>> ><br>
>> > In numerical computing the use-case is extremely common, in fact I would say<br>
>> > it practically universal. Ideally it would be vectorized, but in practice<br>
>> > this is often not possible, requiring the use of loops.<br>
>><br>
>> Can you give a more specific example? I believe your problem is real,<br>
>> but as a numerical programmer I can't think of an example of where<br>
>> I've ever wanted anything like this, so it's hard for me to visualize<br>
>> what exactly you're talking about.<br>
><br>
><br>
> Here is one right from the scipy cookbook:<br>
> <a href="http://wiki.scipy.org/Cookbook/Theoretical_Ecology/Hastings_and_Powell">http://wiki.scipy.org/Cookbook/Theoretical_Ecology/Hastings_and_Powell</a><br>
> 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).</p>
<p dir="ltr">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.</p>
<p dir="ltr">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.</p>
<p dir="ltr">> Some other examples:<br>
> 1. Anything done in parallel on a range of values (here is an example, although they don't give the actual algorithm <a href="http://stackoverflow.com/questions/11210677/need-help-to-parallelize-a-loop-in-python">http://stackoverflow.com/questions/11210677/need-help-to-parallelize-a-loop-in-python</a>)</p>
<p dir="ltr">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.</p>
<p dir="ltr">> 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)</p>
<p dir="ltr">This sounds similar to the previous two cases too.</p>
<p dir="ltr">> 3. Many types a stair step adaptive approaches in experiments (<a href="http://en.wikipedia.org/wiki/Psychophysics#Staircase_procedures">http://en.wikipedia.org/wiki/Psychophysics#Staircase_procedures</a>)</p>
<p dir="ltr">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?</p>
<p dir="ltr">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.</p>
<p dir="ltr">-n</p>