OK. If you want to put the "trivial modifications" that are required so the code is "on par with what we had usually committed as new contributions" in the JIRA incident, I can try to address them this week as well.
On Mon, Oct 20, 2014 at 5:51 PM, Gilles <gil...@harfang.homelinux.org> wrote: > On Mon, 20 Oct 2014 19:33:25 +0200, Luc Maisonobe wrote: > >> Le 20/10/2014 16:00, Hank Grabowski a écrit : >> >>> I have some time this week to try to get these changes made to the >>> interpolators. I don't want to do anything without consensus however. >>> So >>> to try to incorporate the discussion above plus a concerned raised over >>> the >>> weekend on the JIRA thread I propose: >>> >>> 1. Adding the original functionality back so that the original classes >>> are >>> there, but adding deprecation and very explicit warnings to the >>> documentation that they should not be used. One release ahead of this I >>> think they should be removed however. >>> 2. Move my code into a new PiecewiseBicubicSpline classes. >>> >>> The changes I discussed in the e-mail that Giles referred to above I will >>> be making to these new PiecewiseBicubicSpline classes, and the >>> TricubicSpline i will do the same Piecewise surname rather than replacing >>> the classes. >>> >>> I do not want to do this with backing outt the existing pull request. I >>> will simply make the changes and then initiate a follow-up one. >>> >>> How does that sound to everyone? We need to get accurate interpolators >>> in >>> the next release, so the sooner I can squeeze this into my schedule to >>> get >>> this committed the better. >>> >> >> It sounds good to me, but I prefer to wait for Gilles analysis as he is >> more aware than me of any problems on this topic. >> >> > I'm fine with the plan, as long as we've agreed that whatever is > committed is an "experimental" version, still subject to change > until everybody is satisfied with the new design. > [I'm not referring to the main functionality; I of course agree > that accurate interpolation should be made available. But from > what I've seen, trivial modifications are required to set the > code on a par with what we had usually committed as new > contributions.] > > Regards, > Gilles > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
