commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <phil.ste...@gmail.com>
Subject Re: [math] proposing a new interpolator that does *not* implement UnivariateInterpolator
Date Sun, 17 Jun 2012 17:16:21 GMT
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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message