WIP: min, max, sum, prod, mean etc on dimensions

[blakejohnson]

First pass at implementing the Dim type from the discussion #2265. For an array A, you can now call, e.g.: max(A, Dim(1)). The Dim can be constructed with integers,
arrays, ranges, or tuples, so all of the following are valid:

Dim(1)
Dim(1, 2)
Dim([1])
Dim([1,2])
Dim([1 2])
Dim(1:2)

I seem to have broken something with BitArrays which I am yet to figure out.

Still need to modify cumsum and cumprod. All the stats functions need similar updates.

[pao]

Travis failures don't appear to be your fault. Filing new issues for them.

[stevengj]

Dim should take any iterable collection of integers, which could be implemented via:

Dim(d) = Dim(Int[i for i in d])

with no need for special cases for Range, Tuple, Int, etcetera.

But I'm not completely sold on the whole Dim syntax in general.

[blakejohnson]

@stevengj How do I get that to work while also supporting Dim(1, 2, 3...)?

[stevengj]

Dim(arg1, arg2, args...) = Dim([arg1,arg2,args...])

[blakejohnson]

@stevengj Apparently a Range is an AbstractVector. So, if I make just these two outer constructors:

Dim(d) = Dim(Int[d[i] for i=1:length(d)])
Dim(d1, d2...) = Dim([d1, d2...])

then a call to Dim(1:3) doesn't vectorize the range.

[kmsquire]

It probably shouldn't really matter if range isn't vectorized, e.g.,

julia> z = zeros(2,2,2,2); z[:]=1:16; sum(z, 1:4)
1x1x1x1 Float64 Array:
[:, :, 1, 1] =
 136.0

[stevengj]

Why waste storage by converting a range into an explicit vector of elements?

[pao]

On further review, #2411 might actually be caused by this, so please look into that if we're going to pursue this further.

[blakejohnson]

@pao yes, I do think the BitArray issues are caused by my changes. However, the winds seem to shifting away from this approach over in #2265. So, I am going to hold off on further development until that issue is settled.

[pao]

Fair enough. I'll go ahead and close #2411 to get it off the radar, then.

[StefanKarpinski]

I have to say, I really don't care for the Dim type approach. This is a solid implementation of it, but it really rubs me the wrong way. I think we should just be draconian about the second argument of functions that accept dimension specifications being the dimension and introduce alternate function names for versions that do something else, e.g. varm(m,v,[d]) and stdm(m,v,[d]) for variance and standard deviation calculations with known means.

[blakejohnson]

@StefanKarpinski I'm with you on the varm, stdm, etc... I'll have a go at implementing it and open a new pull request.

[johnmyleswhite]

I also really like the varm, stdm approach. I basically never need those functions.

[StefanKarpinski]

"Varm" also means "warm" in Swedish, which gives me an, er, warm and fuzzy feeling.

[toivoh]

@StefanKarpinski: Yeah, that felt pretty funny to me too. Do you know Swedish?

[StefanKarpinski]

I do – my mother's from Sweden and it was my first language.

[toivoh]

Aha, där ser man. Fast det är nog bättre att vi pratar engelska här ändå.

[StefanKarpinski]

Kanske vi skulle översätta dokumentationen til svenska? Nä... alla svenskar föstår engelska ändå.

[toivoh]

Precis :)

[blakejohnson]

Since the max/min solution is still being discussed, I am re-opening this pull request. I've fixed the test failures. If we decide to continue with this approach, I could use a suggestion for a less hacky means of comparing the regions in suitespare.jl's reducedim function.

[blakejohnson]

Closing, as stdm and varm are implemented in #2561, and it seems we are waiting on keyword args to fix max(v, (), dim).