On 4/30/14, 5:58 AM, Andrej Mitrovic via Digitalmars-d wrote:
> On 4/30/14, Andrei Alexandrescu via Digitalmars-d
> <digitalmars-d@puremagic.com> wrote:
>> On 4/29/14, 11:08 AM, bearophile wrote:
>>> In Phobos there are awkward names like walkLength
>>
>> Love it. -- Andrei
>
> std.algorithm.count also works with any input range, they can use that
> if they don't like walkLength. Unless it has some limitations? I can't
> think of any.

Yah, they overlap in functionality but only somewhat. walkLength is O(1) on ranges with length, and it allows a convenient "up to" parameter.

Andrei

On 4/30/14, 6:18 AM, "Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang@gmail.com>" wrote:
> On Wednesday, 30 April 2014 at 11:52:14 UTC, Dicebot wrote:
>> And that would have been quite a close guess actually as walkLength is
>> constrained to accept only finite InputRanges :) "walk" here implies
>> iteration and iteration implies O(n).
>
> The common term is "count", "countNodes", "countElements" etc... Why all
> the specialized functions in algorithm.d? Why not just have a default
> predicate that is always true and do compile time optimizations?

That would be an awful idea. -- Andrei

On Wednesday, 30 April 2014 at 15:51:09 UTC, Andrei Alexandrescu wrote:
>> Why all
>> the specialized functions in algorithm.d? Why not just have a default
>> predicate that is always true and do compile time optimizations?
>
> That would be an awful idea. -- Andrei

Why?

By having a gazillion functions doing almost the same thing you are moving away from generic programming…

On Wednesday, 30 April 2014 at 15:45:32 UTC, Andrei Alexandrescu wrote:
>> The name should indicate what you get (the calculating of a result), not
>> how the framework obtains it (sequential scan).
>
> Making complexity an implementation detail is an antipattern. -- Andrei

Where did I say that?

On Wednesday, 30 April 2014 at 16:48:50 UTC, Ola Fosheim Grøstad wrote:
> On Wednesday, 30 April 2014 at 15:45:32 UTC, Andrei Alexandrescu wrote:
>>> The name should indicate what you get (the calculating of a result), not
>>> how the framework obtains it (sequential scan).
>>
>> Making complexity an implementation detail is an antipattern. -- Andrei
>
> Where did I say that?

I think the thrust of the statement is this: by shoving under the rug the method by which the length is obtained, it also conceals the algorithmic complexity and hinders good judgement on what tradeoffs are being made.

I can see the argument for either position, really.  Personally, I think "calculate" sufficiently denotes that there's nontrivial work going into the process, but "walk" makes it fairly clear that O(n) should be expected.

It's an awkward discussion because neither is very discoverable in the first place; maybe make one an alias for the other and give people a sporting chance to find the damn thing?

-Wyatt

On Wednesday, 30 April 2014 at 19:55:08 UTC, Wyatt wrote:
> It's an awkward discussion because neither is very discoverable in the first place; maybe make one an alias for the other and give people a sporting chance to find the damn thing?

With an IDE discoverable probably means that it follows the conventions of the language for the first phrase. I.e. it should start with "length" so that it pops up when you start typing "len…". Well, if it is callable with dot-notation.

I know from experience that I avoid using functions that I don't remember the name of. That is one reason I use list comprehensions so much in Python. The more dedicated functions takes time to look up. I think large sections of Python's standard library could be wiped out in favour of the more powerful abstractions and mechanisms it has now.

And even if a very narrow function might be faster, I probably will write my own loop if speed is that important. So I would favour fewer and more generic functions, with better optimization.

(I think you can get a long way by just using templates, but others have suggested AST macros, and pattern/matching term rewriting is also a possibility.)