On Thu, Oct 16, 2014 at 10:22 AM, Nathaniel Smith <n...@pobox.com> wrote:
> On Tue, Oct 14, 2014 at 10:33 PM, Charles R Harris > <charlesr.har...@gmail.com> wrote: > > > > On Tue, Oct 14, 2014 at 11:50 AM, Nathaniel Smith <n...@pobox.com> wrote: > >> > >> On 14 Oct 2014 18:29, "Charles R Harris" <charlesr.har...@gmail.com> > >> wrote: > >> > > >> > > >> > > >> > On Tue, Oct 14, 2014 at 10:57 AM, Nathaniel Smith <n...@pobox.com> > wrote: > >> >> > >> >> On 4 Oct 2014 22:17, "Stéfan van der Walt" <ste...@sun.ac.za> wrote: > >> >> > > >> >> > On Oct 4, 2014 10:14 PM, "Derek Homeier" > >> >> > <de...@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@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@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
