min/max reductions are confusing

[JeffBezanson]

The generic max(itr) calls max on pairs of values, while max(Array) calls > on pairs of values. This is a problem because max(A::Array,B::Array) is elementwise, while all other definitions of max(A,B) return either A or B depending which is "larger".

At the very least, all 1-argument max definitions should be consistent on whether they do reduce(max, ...) or call >.

Then we are just left with the elementwise behavior, which may be a fight for another day.

[JeffBezanson]

Worth noting that we solve this problem in other cases by giving the reducing function a different name: + => sum, * => prod. It would be nice to do this for min and max too, but it's hard to think of names, other than maybe max => maximum, or maybe maximal.

[mschauer]

An alternative view would be that rather max and (a > b ? a : b) should agree and the piecewise maximum could receive a new name, e.g. pmax as in R (because .max would be very exotic.)

[JeffBezanson]

I would be ok with a solution like that too.

[JeffBezanson]

I think we should get this into 0.2 since it's a potentially breaking API change. In particular we must get rid of the awful max(A, (), dim) methods.
cc @ViralBShah @StefanKarpinski

[timholy]

Agreed that this is a noteworthy wart.

[lindahua]

I agree that the choice of using max for both the element-wise operation that takes the larger values and the reduction to get the maximum was unfortunate. It causes all this mess and also forces us to use the ugly syntax like max(A, (), dim).

I am in favor of using maximum and minimum for the reduction purpose, and am more than happy to fix any issues caused by this breakage in the packages maintained by me. That being said, we should be cautious though, as this would be a major API change, given how widely these functions may have been used.

[blakejohnson]

We tried to fix this before by renaming the multi-arg versions of max and min to maxof and minof in #2419. I like the name, but as you can see it required changing many uses of max and min.

[lindahua]

I suspect that renaming the reduction versions from max and min to maximum and minimum might be relatively easier than renaming max(a, b) to maxof(a, b), as the latter seems to be used much more frequently.

[blakejohnson]

@lindahua I think you are right.

[johnmyleswhite]

+1 for Dahua's names.

[JeffBezanson]

I'm fine with that renaming. It solves the () problem, but then there is the elementwise behavior. Would maximum(A) do reduce(max, A), or pick the largest element according to >? If max(a,b) were not elementwise, those two would be the same.

[StefanKarpinski]

Here's an idea. The min and max functions without a dim keyword argument do reduction over each argument and then return the min/max across arguments – they're basically maximally greedy. If you give a dim keyword argument with a single input array, then reduce those dimensions of it. If you give multiple array arguments with a dim keyword, then each argument is dimension reduced and then parallel min/max is done across the reduced results. Examples:

min(1,2) => 1
min([1, 2, 3], 10, [0]) => 0
min([1, 2, 3], [4, 5, 6]) => 1
min([1 2 3; 3 2 1], dim=1) => [1 2 1]
min([1 2 3; 3 2 1], dim=2) => [1 1]'
min([1 2 3; 3 2 1], [2 0 2] dim=1) => [1 0 1]
min([1 2 3; 3 2 1], [3 2 1; 1 2 3] dim=()) => [1 2 1; 1 2 1]

I think this is equivalent to having dim default to 1:n where n is the maximum number of dimensions of its arguments, with the convention that reducing along dimensions that something doesn't actually have isn't an error, but rather just works. I think this smoothly dovetails the two meanings of min and max without introducing new function names and it generally Just Works™.

[JeffBezanson]

Not a bad idea, but I'm worried about all that reducing. Would max("ab","bc") still give "bc", or 'c'?