gradient(): remove from Base, then deprecate

[stevengj]

gradient(1:10) doesn't work because it dispatches to a method that only takes Array arguments.

Also, gradient doesn't support multi-dimensional arrays, whereas in Matlab and NumPy it returns an N-tuple of the gradients along different directions.

cc: @andreasnoack, who looked at these functions in #5321.

[stevengj]

Also, the current implementation allocates a lot of temporary arrays. Not sure if we care about the performance of this function, though.

[tkelman]

The presence of this function in base is pretty annoying from a JuliaOpt / AD perspective. Do we need to keep it here?

[andreasnoack]

The function has received almost no attention over the years. I only fixed a small obvious error reported in #5320 and have never really used it. The gradients I use are those that @tkelman mentions.

[johnmyleswhite]

I would love to see this function removed.

[stevengj]

I don't have strong opinions about this function; I know that it has a long lineage (e.g. it is in Matlab and NumPy), but I doubt I've used it more than a couple of times in my life. However, it is useful for plotting purposes, e.g. for quick gradient plots in 2d or plots of the slope of a curve. That's probably why it exists.

[StefanKarpinski]

My vote: deprecate and leave as-is.

[kshyatt]

I added the decision label to this because it seems there's some controversy. Whichever way we decide it's still an intro issue but it seems like someone ought to decide.

[stevengj]

Seems like the clear consensus is to leave as-is and deprecate.

[tkelman]

Yep. Though usually when we deprecate things we suggest a replacement. So we should pick some package to migrate this to, and the package can go ahead and deal with the input types. If it's mostly used for plotting, Graphics.jl maybe?

[stevengj]

Graphics.jl is more about drawing than plotting, so I don't think it's appropriate. It's not really clear to me that there is any package in common to all plotting, except maybe ColorTypes.jl, but gradient doesn't belong there.

There is a gradient function in FiniteDiff.jl by @johnmyleswhite, but the semantics are somewhat different. I guess he has gradient(f::Function) there; I suppose he could add gradient(::AbstractArray).

[musm]

curl is also a quick and dirty MATLAB function that has seen my use. Would these all appropriately fit in a special function package (even though they're not what one would typically regard as a special function)

[tkelman]

MatlabCompat or an independent VectorCalculus package could work. Most packages that do gradients mean the functional gradient rather than gradient vector fields.

[kmsquire]

FWIW, there is also a gradient function in Images.jl, which calculates the gradient vector field. But the 1D version doesn't really fit there...