[Numpy-discussion] any interest in including asecond-ordergradient?
Wed Oct 29 12:46:55 CDT 2008
Minor comment on all this, from the peanut gallery...
Without commenting on the original gradient API or changes, I'm a
strong -1000 on introducing the notion of 'order' into a gradient
function. The gradient, from every definition I can remember, is a
first-order operation. Matlab's gradient is written this way:
and for good reason: nobody speaks of 'second order gradients'. The
gradient is an operation defined for functions f:R^n -> R as the
vector of all first partial derivatives, end of story. In numpy lingo
a function like this is represented by an N-d array, and we're all OK
with that analogy. But I really think that gradient() in numpy should
stick to what the math literature has defined up until now.
I think it's fine to ask for functions that compute higher order
derivatives of n-d arrays: we already have diff(), which operates on a
single direction, and a hessian could make sense (with the caveats
David points out). But with higher order derivatives there are many
more combinations to worry about, and I really think it's a bad idea
to lump those issues into the definition of gradient, which was a
perfectly unambiguous object up until this point.
Just my devalued U$ 1e-2...
More information about the Numpy-discussion