[Numpy-discussion] Changed behavior of np.gradient

Charles R Harris charlesr.harris at gmail.com
Tue Oct 14 17:33:14 EDT 2014


On Tue, Oct 14, 2014 at 11:50 AM, Nathaniel Smith <njs at pobox.com> wrote:

> On 14 Oct 2014 18:29, "Charles R Harris" <charlesr.harris at gmail.com>
> wrote:
> >
> >
> >
> > On Tue, Oct 14, 2014 at 10:57 AM, Nathaniel Smith <njs at pobox.com> wrote:
> >>
> >> On 4 Oct 2014 22:17, "Stéfan van der Walt" <stefan at sun.ac.za> wrote:
> >> >
> >> > On Oct 4, 2014 10:14 PM, "Derek Homeier" <
> derek at astro.physik.uni-goettingen.de> wrote:
> >> > >
> >> > > +1 for an order=2 or maxorder=2 flag
> >> >
> >> > If you parameterize that flag, users will want to change its value
> (above two). Perhaps rather use a boolean flag such as "second_order" or
> "high_order", unless it seems feasible to include additional orders in the
> future.
> >>
> >> Predicting the future is hard :-). And in particular high_order= would
> create all kinds of confusion if in the future we added 3rd order
> approximations but high_order=True continued to mean 2nd order because of
> compatibility. I like maxorder (or max_order would be more pep8ish I guess)
> because it leaves our options open. (Similar to how it's often better to
> have a kwarg that can take two possible string values than to have a
> boolean kwarg. It makes current code more explicit and makes future
> enhancements easier.)
> >
> >
> > I think maxorder is a bit misleading. The both versions are second order
> in the interior while at the ends the old is first order and the new is
> second order. Maybe edge_order?
>
> Ah, that makes sense. edge_order makes more sense to me too then - and we
> can always add interior_order to complement it later, if appropriate.
>
> The other thing to decide on is the default. Is the 2nd order version
> generally preferred (modulo compatibility)? If so then it might make sense
> to keep it the default, given that there are already numpy's in the wild
> with that version, so we can't fully guarantee compatibility even if we
> wanted to. But what do others think?
>
I'd be inclined to keep the older as the default and regard adding the
keyword as a bugfix. I should have caught the incompatibility in review.

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20141014/4dfc0fb9/attachment.html>


More information about the NumPy-Discussion mailing list