Le 31/10/2010 17:59, Gilles Sadowski a écrit : > On Sun, Oct 31, 2010 at 03:57:33PM +0100, Luc Maisonobe wrote: >> Le 31/10/2010 15:08, Gilles Sadowski a écrit : >>> Hi. >>> >>> [Continued from the previous message.] >>> >>> Accepting that the interpolation abscissae are not sorted in strictly >>> increasing order make it necessary to check (at every call to the "value" >>> method) that no 2 interpolating points are the same. >>> The code would be cleaner is we assume (as a pre-condition) that the "x" >>> interval is sorted. [And it would be more similar to other interpolating >>> classes that explicitely prohibit unsorted interpolation intervals.] >> >> So I guess you would put this check in the verifyInterpolationArray >> method which is called from constructor and remove the d == 0 check in >> computeCoefficient ? > > Yes. > >> Beware that the static evaluate method can be called directly from >> outside. We need to keep this public method, so we may perhaps split it >> as a check followed by a call to a private internal method that does no >> check, whereas the value instance method would directly call the >> no-check version since the check would have been done beforehand in the >> constructor. > > This is exactly what I've already implemented. > What remains is the "problem" of allowing unsorted input arrays. > >>> >>> If we nevertheless want to allow the user to pass an unsorted interval, I'd >>> rather have a new utility method that would sort the "x" interval (and apply >>> the corresponding permutations to "y") within the constructor. > > So, what do you think of just require that the array be sorted? > [This would imply changing the test, where the array is not sorted.]
Perhaps we could add a boolean parameter isAlreadySorted or needSorting to the constructor and perform the sort only when needed ? Luc > > > Gilles > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
