merge cumprod rules to fix ambig on julia 1.6

[oxinabox]

Suggested by @devmotion in #781
should resolve same issue.
I am not sure which is cleaner

[github-actions]

[JuliaFormatter] _{reported by reviewdog 🐶}

Suggested change

	end
	,
	@thunk project_x(if dims <= ndims(x)
	vald = Val(Int(dims))
	∇cumprod_dim(vald, x, dy, y)
	if ndims(x) == 1
	∇cumprod(x, dy, y)
	else
	vald = Val(Int(dims))
	∇cumprod_dim(vald, x, dy, y)
	end
	else
	dy
	end)
	end,
	@thunk project_x(
	if dims <= ndims(x)
	if ndims(x) == 1
	∇cumprod(x, dy, y)
	else
	vald = Val(Int(dims))
	∇cumprod_dim(vald, x, dy, y)
	end
	else
	dy
	end,

[devmotion]

I think I'm slightly in favour of this PR, since it reduces the number of methods and cumprod(::AbstractVector) is forwarded to the keyword argument version: https://github.com/JuliaLang/julia/blob/63e95d47e692352fac5541b6ee835b573f4c4898/base/accumulate.jl#L227

Unfortunately, the diff is significantly larger than in #781 - and it requires a few additional changes to the tests since there's no rrule(cumprod, ::AbstractVector) anymore (so one has to set dims=1 explicitly in these tests).

[devmotion]

Is it OK to put a default value for dims even though there's no default value in base? https://github.com/JuliaLang/julia/blob/63e95d47e692352fac5541b6ee835b573f4c4898/base/accumulate.jl#L193

[oxinabox]

yes, it is see:
#784 (comment)

[oxinabox]

its actually fine for the rrule to always default dims to 1. (So I have made that change)
Since:

• in the vector case this is what is wanted and is the correct default
• in the nonvector case then a keyword argument is required by the primal, so the default will never be hit.

[mcabbott]

in the nonvector case then a keyword argument is required by the primal, so the default will never be hit.

What does this mean? The primal computation is done inside the rrule, and does use the default.

I think that will mean gradient(x -> sum(abs, cumprod(x)), [1 2; 3 4.]) is not an error, whereas without gradient it would be.

That said, I have no memory of why there are two rrules. Besides this issue there might have been performance concerns?

[oxinabox]

I think that will mean gradient(x -> sum(abs, cumprod(x)), [1 2; 3 4.]) is not an error, whereas without gradient it would be.

That is a point.
I had been thinking we could rely on the primal computation being correct.
But I guess we can not.

We will have to do somehting more complex like set the rrule as dims=nothing
then if ndims(x)==1 set it to dims=1

[devmotion]

We will have to do somehting more complex like set the rrule as dims=nothing

Can't we just omit the default value and adjust the tests?

[mcabbott]

My vote is that #781 is much simpler.

Besides worrying about error cases, I think this kind of change would want to be checked very carefully for type stability or performance regressions.