Per the recent discussion comparing D with Lua, tests suggest that iota for double is too slow. This is a necessity if iota is a bidirectional or random-access range. If we allow it to be a forward range, then performance would be significantly increased.

Do you agree with making iota for floating-point types a forward range?


Andrei

I vote for leaving iota as is.  Reasoning:

1. In general, premature micro-optimization is a Bad Thing.  A standard library should aim to be correct, general and reasonably efficient and handle the 95% of cases well.  If you need micro-optimization or are otherwise in that hardest 5%, you have the core language in which to roll your own widget.

2.  In the case of quick and dirty code, the user probably won't care much about the speed advantage of using a forward range, and may do something silly like eagerly evaluate using array() if he/she needs a bidirectional/random access range, thus worsening the performance problem instead of solving it.

3.  In the case of higher quality code, iota as it currently stands is only a problem in performance critical code that doesn't need anything beyond forward access.  If someone really needs the speed, it's trivial to roll one's own iota equivalent that offers only forward access, or even manually inline and hand optimize it for possibly even more speed. If the forward range version of iota were the default and someone needed the bidirectional/random version, it would be less trivial to roll one's own, as the user might miss the subtle details that make Phobos's current implementation correct.

On 12/23/2010 1:20 PM, Andrei Alexandrescu wrote:
> Per the recent discussion comparing D with Lua, tests suggest that iota for double is too slow. This is a necessity if iota is a bidirectional or random-access range. If we allow it to be a forward range, then performance would be significantly increased.
>
> Do you agree with making iota for floating-point types a forward range?
>
>
> Andrei
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
>

These are reasonable arguments, and I'd agree a lot more if I didn't also believe that bidirectional and random access of iota ranges is extremely rare. So it looks like we're hurting the common case for the sake of a potential but obscure and rarely realized generality.

Andrei

On 12/23/10 12:49 PM, David Simcha wrote:
> I vote for leaving iota as is. Reasoning:
>
> 1. In general, premature micro-optimization is a Bad Thing. A standard library should aim to be correct, general and reasonably efficient and handle the 95% of cases well. If you need micro-optimization or are otherwise in that hardest 5%, you have the core language in which to roll your own widget.
>
> 2. In the case of quick and dirty code, the user probably won't care much about the speed advantage of using a forward range, and may do something silly like eagerly evaluate using array() if he/she needs a bidirectional/random access range, thus worsening the performance problem instead of solving it.
>
> 3. In the case of higher quality code, iota as it currently stands is only a problem in performance critical code that doesn't need anything beyond forward access. If someone really needs the speed, it's trivial to roll one's own iota equivalent that offers only forward access, or even manually inline and hand optimize it for possibly even more speed. If the forward range version of iota were the default and someone needed the bidirectional/random version, it would be less trivial to roll one's own, as the user might miss the subtle details that make Phobos's current implementation correct.
>
> On 12/23/2010 1:20 PM, Andrei Alexandrescu wrote:
>> Per the recent discussion comparing D with Lua, tests suggest that iota for double is too slow. This is a necessity if iota is a bidirectional or random-access range. If we allow it to be a forward range, then performance would be significantly increased.
>>
>> Do you agree with making iota for floating-point types a forward range?
>>
>>
>> Andrei
>> _______________________________________________
>> phobos mailing list
>> phobos at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/phobos
>>
>
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos

On Thu, 23 Dec 2010 12:52:31 -0600
Andrei Alexandrescu <andrei at erdani.com> wrote:

> These are reasonable arguments, and I'd agree a lot more if I didn't also believe that bidirectional and random access of iota ranges is extremely rare. So it looks like we're hurting the common case for the sake of a potential but obscure and rarely realized generality.

I agree. Python's "range" is similar to iota: I have never needed more than plain forward traversal, and never read any code that needs more.

Denis
-- -- -- -- -- -- --
vit esse estrany ?

spir.wikidot.com

On Thursday 23 December 2010 10:52:31 Andrei Alexandrescu wrote:
> These are reasonable arguments, and I'd agree a lot more if I didn't also believe that bidirectional and random access of iota ranges is extremely rare. So it looks like we're hurting the common case for the sake of a potential but obscure and rarely realized generality.

Didn't you already suggest splitting iota into two different functions/types so that one was forward-range only and one was random access? Given the definite loss in efficiency of dealing with floating-point values correctly with random access, I don't think that it's reasonable to leave iota as is - particularly since in most cases, iota wil probably not need random or bi-directional access.

- Jonathan M Davis

On Thu, 23 Dec 2010 11:20:24 -0700, Andrei Alexandrescu <andrei at erdani.com> wrote:

> Per the recent discussion comparing D with Lua, tests suggest that iota for double is too slow. This is a necessity if iota is a bidirectional or random-access range. If we allow it to be a forward range, then performance would be significantly increased.
>
> Do you agree with making iota for floating-point types a forward range?
>
>
> Andrei

I had thought the major slowdown was using code like 'start + step * i' as opposed to 'current += step', which, although much faster is fundamentally broken, as with floating point numbers x = (x+1), etc. Am I mistaken?

On 12/23/10 10:33 PM, Robert Jacques wrote:
> On Thu, 23 Dec 2010 11:20:24 -0700, Andrei Alexandrescu <andrei at erdani.com> wrote:
>
>> Per the recent discussion comparing D with Lua, tests suggest that iota for double is too slow. This is a necessity if iota is a bidirectional or random-access range. If we allow it to be a forward range, then performance would be significantly increased.
>>
>> Do you agree with making iota for floating-point types a forward range?
>>
>>
>> Andrei
>
> I had thought the major slowdown was using code like 'start + step * i' as opposed to 'current += step', which, although much faster is fundamentally broken, as with floating point numbers x = (x+1), etc. Am I mistaken?

Indeed you are correct.

Andrei

On Thu, 23 Dec 2010 22:45:07 -0700, Andrei Alexandrescu <andrei at erdani.com> wrote:

> On 12/23/10 10:33 PM, Robert Jacques wrote:
>> On Thu, 23 Dec 2010 11:20:24 -0700, Andrei Alexandrescu <andrei at erdani.com> wrote:
>>
>>> Per the recent discussion comparing D with Lua, tests suggest that iota for double is too slow. This is a necessity if iota is a bidirectional or random-access range. If we allow it to be a forward range, then performance would be significantly increased.
>>>
>>> Do you agree with making iota for floating-point types a forward range?
>>>
>>>
>>> Andrei
>>
>> I had thought the major slowdown was using code like 'start + step * i' as opposed to 'current += step', which, although much faster is fundamentally broken, as with floating point numbers x = (x+1), etc. Am I mistaken?
>
> Indeed you are correct.
>
> Andrei

Then may I suggest we keep the correct, but slow, behavior for floats and put a note in the docs on the performance/implementation? (Or at least internally use reals internally to help mitigate the problem)