On 6/17/12 9:46 AM, Luc Maisonobe wrote: > Hi all, > > I recently encountered a cumbersome limitation with our current > UnivariateInterpolator interface. It is a simple interface that defines > only one method: > > public interface UnivariateInterpolator { > UnivariateFunction interpolate(double xval[], double yval[]); > } > > I needed three different features which are not compatible with this > interface. > > 1) the function values are vectorial, not scalar > 2) the interpolation should use values and also derivatives at sample > points if provided > 3) it should be possible in the same interpolation to provide > derivatives at some points and no derivatives at other points > (or derivatives with different orders) > > I thought about adding a UnivariateVectorInterpolator with an API > similar to the existing one, but finally thought it would be really > awkward. As the function is a vector function, both xval and yVal should > have a second dimension. As derivatives should be added, the yVal > array should in fact have a third dimension. As some derivatives should > be optional, some rows of yVal should be allowed to be null. At this > step, I considered packing everything in two arrays was not the way to go. > > So I designed something different. For now, I have implemented it in > Orekit but I really think it does belong to [math] scope, so I would > like to commit it there. The code is available here: > <https://www.orekit.org/forge/projects/orekit/repository/revisions/e0f647bd7cd1450bd361dfcaf9530892c285dc47/entry/src/main/java/org/orekit/utils/HermiteInterpolator.java>. > > The design is based on building the interpolator iteratively. At > construction, it is empty, then successive calls to addSamplePoint are > made, one call for each points. The signature of the method is: > > public void addSamplePoint(final double x, final double[] ... value); > > The user can provide only one array for some points, or two arrays if > first derivatives are available for this point, or three arrays is > second derivative is also available and so on. The elements of each > array correspond to the vectorial components of the function. Users can > mix freely calls with and without derivatives. > > At the end, the user can get the value of the function or its first > derivative at a some abscissa without building the intermediate function > or he can prefer to build this function and retrieve it as a polynomial > (see methods value, derivative and getPolynomial). In fact, it is > possible to add some points, interpolate on these points, add new > points, and interpolate again using all the points. > > So I would like to commit this class. However, I'm not sure if it should > be simply added to the analysis.interpolation package as is, of if the > API should be modified. I don't know either if we should set a top level > interface for this or not. > > What do you think ?
Interesting class. I would say add it separately to analysis.interpolation. The existing univariate interpolator is what is says it is. The new thing is for vector-valued functions and also takes more arguments. We should strive to make the most basic functionality easy to find and understand, so I would not mess with trying to generalize the simple univariate setup. Regarding the design of the new class, I am not in love with the varargs setup in addSamplePoint, but see no simple way around it if you are likely to in fact get arbitrarily high (>2?) order derivatives passed in. In the javadoc, you should also make it clear that first derivatives returned are not guaranteed to match actual parameters when supplied (unless I am missing something). One other nit is that addSamplePoint javadoc refers to actual parameter y, but this should be "value." Phil > > best regards, > Luc > > > --------------------------------------------------------------------- > 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