[Issue 4705] Redesign of std.algorithm.max()/min() + mins()/maxs()

[d-bugmail at puremagic.com]

http://d.puremagic.com/issues/show_bug.cgi?id=4705



--- Comment #13 from bearophile_hugs at eml.cc 2011-10-12 15:55:39 PDT ---
Part of A comment by Andrei Alexandrescu:
http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=144562

> Second, you propose
> 
> mins(collection)
> mins!(callable)(collection)
> maxs(collection)
> maxs!(callable)(collection)
> 
> that return all elements. I'm not sure how you plan to return - create a
> new array, or iterate a la filter? The latter is interesting, but for
> either variant is quite difficult to find use examples that are frequent
> enough to make min followed by filter too verbose.

It's not a problem of verbosity. If you have to find all the min or max items
of a lazy iterable, and you want to use min followed by filter, then you have
to scan the sequence two times. This is a problem because:
- Two scans are a waste of time if the sequence is a large array, because of
CPU cache issues.
- It becomes worse if the sequence is a lazy range, because you have to compute
every item two times. This is sometimes not acceptable. I have found situations
like this, where the range was coming from a map with a costly mapping
function.

So maxs/mins is a common enough pattern (I have just hit another use case),
it's not trivial to implement manually (because you have to efficiently manage
the cache of the max/min items found so far), and I think it can't be trivially
and efficiently implemented using existing std.range/std.algorithm tools. This
makes it a worth candidate for a specilized higher order function.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------