[Numpy-discussion] Changed behavior of np.gradient

[Benjamin Root]

It isn't really a question of accuracy. It breaks unit tests and
reproducibility elsewhere. My vote is to revert to the old behavior in
1.9.1.

Ben Root

On Thu, Oct 16, 2014 at 6:10 PM, Ariel Rokem <arokem at gmail.com> wrote:

>
> 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!
>
>
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20141016/0abbffad/attachment.html>