commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luc Maisonobe <>
Subject Re: [math] proposing a new interpolator that does *not* implement UnivariateInterpolator
Date Sun, 17 Jun 2012 18:44:53 GMT
Hi Phil,

Le 17/06/2012 19:16, Phil Steitz a écrit :
> 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:
>> <>.
>> 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.

I agree. A too general setup is often very awkward to use.

> 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.

The typical examples I have in mind use mainly the first derivative, but
in some cases (attitude control with patched sequences for agile Earth
observation satellites), users need to match velocity, acceleration and
jerk, i.e. up to third derivative between the sequences. I may also need
this for Nordsieck vector computation in multistep ODE (I really should
make these solvers more robust). For Nordsieck vectors, we basically use
only one point, but as many derivatives as the solver order (it may be
10 or 12).

> 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).

No, they really match the provided values (except for numerical
inaccuracy, of course), it is not an approximation. You can find some
examples using derivatives in the unit tests here:

> One other nit is that
> addSamplePoint javadoc refers to actual parameter y, but this should
> be "value."

Thanks for spotting this!

best regards,

> Phil
>> best regards,
>> Luc
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message