[Numpy-discussion] any interest in including asecond-ordergradient?

[Fernando Perez]

Howdy,

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:

http://www.mathworks.com/access/helpdesk/help/techdoc/index.html?/access/helpdesk/help/techdoc/ref/gradient.html

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...

Cheers,

f