Complexity nomenclature

Timon Gehr via Digitalmars-d digitalmars-d at puremagic.com
Mon Dec 7 06:43:49 PST 2015


On 12/07/2015 02:46 PM, Andrei Alexandrescu wrote:
> On 12/7/15 5:14 AM, Timon Gehr wrote:
>> D does not allow overloading of syntax to the extent necessary to make
>> similar things really pleasant in the long run, and it has been
>> repeatedly argued that this is a good thing; that custom parsing should
>> be used instead. It is easy to align the parser with D syntax. Anyway,
>> syntax is not the problem here, and the implementation can be downgraded
>> to not support parsing and/or proper names at any point.
>
> I fail to see how no parens after log or "^" in lieu "^^" would make a
> positive difference.

Neither have I attempted to show anything like that. All arguments in 
this debate are obvious and boring, so no need to discuss it.

> What would be a few examples of things that won't
> work pleasantly enough?
> ...

You gave this example:
http://en.cppreference.com/w/cpp/container/forward_list/insert_after

1-2) BigO("1")
3) BigO("count")
4) BigO("distance(first,last)")
5) BigO("ilist.size()")

There's also this:
On 12/06/2015 12:55 AM, Andrei Alexandrescu wrote:
> Well you'd need multiple terms if you want to say things like,
> "inserting a range into an array is O(array[].walkLength +
> r.walkLength)." When you insert a range in a binary search tree, the
> complexity would be O(log(array[].walkLength) * r.walkLength).

BigO("array[].walkLength + r.walkLength");
BigO("log(array[].walkLength) * r.walkLength");




More information about the Digitalmars-d mailing list