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