On 9/16/11 1:24 PM, Simen Kjaeraas wrote:
On Thu, 15 Sep 2011 19:14:24 +0200, Jonathan M Davis
I think that that's up for debate. I would fully expect a min/max
function to
be using a comparator function, which means using a binary predicate.
This seems weird to me. min already has a binary predicate - a < b.
This predicate is what defines min, any other predicate would make it
a different function - usually reduce, unless we're talking about
argMin (does argReduce make any kind of sense?).
That said, there are cases where a < b is not enough, owing to some
types not having a nice and simple comparison. Hence, binary
predicates should also be allowed. I just feel that in the general
case, binary predicates dilute the meaning of min/max. Would you
consider this code good?
min!"a > b"(range);
That's not min, that's max. More:
min!"a.member1 < b.member2"(range);
Again, it's not min, it's something else.
This is a good argument. The "something else" is "extremum"
(http://en.wikipedia.org/wiki/Maxima_and_minima). I suggest:
* Introduce the algorithm "extremum" with a required predicate.
* Introduce extremumCount and extremumPos, both with required predicate.
* Keep minCount and minPos without a predicate. They'd in all likelihood
use extremum.
* Deprecate minCount and minPos with predicate (this is ouchworthy but I
think it won't break a whole lot of code).
* Introduce maxCount and maxPos without predicate.
* Introduce min(range) and max(range) without predicate.
* Introduce argmin and argmax with unary predicate.
Andrei
