[Numpy-discussion] Changed behavior of np.gradient

[Nathaniel Smith]

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