[Numpy-discussion] any interest in including asecond-ordergradient?
Wed Oct 29 11:32:12 CDT 2008
> -----Original Message-----
> From: firstname.lastname@example.org [mailto:numpy-discussion-
> email@example.com] On Behalf Of Robert Kern
> Sent: 28 Oct 2008 3:36 PM
> To: Discussion of Numerical Python
> Subject: Re: [Numpy-discussion] any interest in including asecond-
> On Tue, Oct 28, 2008 at 16:28, Andrew Hawryluk <HAWRYLA@novachem.com>
> > I agree that the gradient functions should be combined, especially
> considering how much redundant code would be added by keeping them
> separate. Here is one possible implementation, but I don't like the
> signature yet as it departs from the current behaviour. At the risk of
> demonstrating my ignorance, is there no way to place the named
> parameter (order) after the variable-length parameter (dx) in Python?
> There's no good way to do it. It's unfortunate that the current
> function uses *args for this. It's just ... not good for many reasons.
> A better one would be like so:
> def gradient(f, dx=None, order=1):
> N = len(f.shape)
> if dx is None:
> dx = np.ones([N])
> elif np.isscalar(dx):
> dx = np.array([dx] * N)
> elif len(dx) == N:
> dx = np.asarray(dx)
> raise ValueError("dx must be blah blah blah")
> Personally, I would make a new function with this API, and deprecate
> the current gradient(). Dunno what the name should be, though.
> Robert Kern
That would be a huge improvement, and only differs from the current
behaviour when it is called on a multidimensional array with different
step sizes in each direction (the least common application, I suspect).
Any chance of using the proposed API with the existing name? What is
deemed sufficient justification for modifying the API of an existing
NumPy function? It causes trouble for existing users, but the number of
future users exceeds the number of existing users, so maybe it is worth
the trouble. If not, you could just call it 'grad' and deprecate the old
one as you suggest.
More information about the Numpy-discussion