[Numpy-discussion] Changed behavior of np.gradient

Ariel Rokem arokem at gmail.com
Thu Oct 16 18:10:24 EDT 2014


On Thu, Oct 16, 2014 at 10:22 AM, Nathaniel Smith <njs at pobox.com> wrote:

> On Tue, Oct 14, 2014 at 10:33 PM, Charles R Harris
> <charlesr.harris at gmail.com> wrote:
> >
> > 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.
>
> I don't have any code that uses gradient, so I don't have a great
> sense of the trade-offs here.
>
> - Usually if we have a change that produces increased accuracy, we
> make the increased accuracy the default. Otherwise no-one ever uses
> it, and everyone gets less accurate results than they would otherwise.
> (I don't have a great sense of how much this change affects accuracy
> though.)
>
> - If the change in output per se is a serious problem for people, then
> it's not one we can fix at this point -- 1.9.0 is out there and people
> are using it anyway, so those who have the problem already need to
> take some affirmative action to fix it. (Also, it's kinda weird to
> change a function's behaviour and add a new argument in a point
> release!)
>
> So I'd like to hear from people affected by this -- would you prefer
> to have the 2nd order boundary calculations by default, you just need
> some way to workaround the immediate problems in existing code? Or do
> you prefer the old default remain the default, with 2nd order boundary
> calculations something that must be requested by hand every time?
>
> -n
>
> --
> Nathaniel J. Smith
> Postdoctoral researcher - Informatics - University of Edinburgh
> http://vorpus.org
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>

Since I started this discussion, I'll chime in. I don't have a strong
preference for either mode that stems from a computational/scientific
principle. As Nathaniel suggested - I have resorted to simply copying the
1.8 version of the function into my algorithm implementation, with the hope
of removing that down the line. In that respect, I have a very weak
preference for preserving the (1.8) status quo per default.

Thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20141016/744f9444/attachment.html>


More information about the NumPy-Discussion mailing list