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. Chuck
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
