This is inconsistent with how non-cumulative functions work in Julia, e.g.:
julia> A = rand(3,4)
3脳4 Array{Float64,2}:
0.239183 0.420538 0.760069 0.349576
0.768802 0.924563 0.934626 0.446843
0.767848 0.761547 0.518525 0.758667
julia> sum(A)
7.650786585136748
julia> cumsum(A)
3脳4 Array{Float64,2}:
0.239183 0.420538 0.760069 0.349576
1.00798 1.3451 1.6947 0.796419
1.77583 2.10665 2.21322 1.55509
Correspondingly, cumsum(A) should, rather than asymmetrically defaulting to the first dimension, either be an error, or return an accumulation of the elements of A such that cumsum(A)[end] == sum(A) and such that cumsum(v')' == cumsum(v) for any vector v. One possibility is performing a cumulative sum in column-major order. Another is that each output value is the sum of values to the values to the left or above that slot in the intput. I.e.:
julia> [sum(A[1:i,1:j]) for i=1:size(A,1), j=1:size(A,2)]
3脳4 Array{Float64,2}:
0.239183 0.65972 1.41979 1.76937
1.00798 2.35308 4.04778 4.8442
1.77583 3.88248 6.0957 7.65079
This answer has the above properties, can be computed efficiently, and is useful.
I agree that cumsum shouldn't default to dim=1 but I think it is better to throw an error if no dimension is specified and ndims>1. I don't like that storage order becomes significant for anything but performance and floating point errors. Short term, there would also be a deprecation issue.
I agree that it's not desirable for storage order to become semantically visible. That's why I proposed the [sum(A[1:i,1:j]) for i=1:size(A,1), j=1:size(A,2)] definition as well. Wanting cumsum(v')' == cumsum(v) may tie into #4774 depending on how that pans out.
The minimal plan of action here is:
accumulate(f, r.').'.In the future, this could be generalized to the n-dimensional prefix summation behavior I proposed above, which is generally useful and ties the desired behavior for vectors and row vectors together.
Most helpful comment
I agree that
cumsumshouldn't default todim=1but I think it is better to throw an error if no dimension is specified andndims>1. I don't like that storage order becomes significant for anything but performance and floating point errors. Short term, there would also be a deprecation issue.