[Numpy-discussion] Changed behavior of np.gradient
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>
> >> >>
> >> >> 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=
> >> >> 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
> >> >> 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
> >> >> kwarg. It makes current code more explicit and makes future
> >> >> easier.)
> >> >
> >> >
> >> > I think maxorder is a bit misleading. The both versions are second
> >> > in the interior while at the ends the old is first order and the new
> >> > second order. Maybe edge_order?
> >> Ah, that makes sense. edge_order makes more sense to me too then - and
> >> 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
> >> 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
> - 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
> 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?
> Nathaniel J. Smith
> Postdoctoral researcher - Informatics - University of Edinburgh
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.org
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the NumPy-Discussion