commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles <>
Subject Re: [math] New 1D Interpolator By-Products
Date Wed, 08 Oct 2014 11:52:56 GMT

On Tue, 7 Oct 2014 14:27:52 -0400, Hank Grabowski wrote:
> All,
> I've been investigating the numerical accuracy issues with the
> BicubicSplineInterpolator.  After re-deriving the equations from the
> original sources (which were correct in the source and the Apache 
> Math
> implementation) and implementing a version in Octave that produced 
> similar
> results it was clear that the original method, while mathematically 
> correct,
> wasn't producing numbers that would be usable for interpolating a 
> field,
> even a planar one.

Thanks a lot for having gone through all that testing; the more so,
that I'm the one who at one point introduced this implementation of
"BicubicSplineInterpolator" without imagining that such bad results
could happen even with a seemingly correct algorithm...
We probably should have removed the functionality from CM as soon as
the problems were detected. I'm sorry for that.

>  I therefore have been implementing a piece-wise cubic
> spline based model.  I have a version coded in Octave that can match 
> planar
> truth functions to within 10^-15 and quadratic truth functions to 
> within
> 10^-13.  The problem with the implementation in Apache Math has been 
> the
> values that have been coming out of the spline interpolators.
> The SplineInterpolator function implements a natural spline 
> algorithm.  I've
> confirmed the outputs of this function against the Math.NET 
> implementation
> and it is producing comparable numbers.  So the implementation of 
> this
> function in Apache Math seems correct.  Unfortunately this algorithm 
> differs
> from the truth function in tests relatively quickly. I therefore 
> coded up
> the Akima Spline Interpolator, borrowing the implementation from the
> Math.NET library (MIT/X11 open source license).  This improves the 
> errors
> considerably but it is still a lot more than what I get within 
> Octave, which
> uses B-splines.
> I am therefore going to be attempting porting the B-spline library 
> from here
> (BSD licensed):
> A few questions:
> 1.       Is there an interest in me keeping the 
> AkimaSplineInterpolator in
> the list of interpolators, assuming that I have a sufficiently 
> rigorous unit
> test harness around it?

I'd say yes.
If the code implements a know algorithm, it's certainly welcome even if
it's not always the best in its category. [There are other suvh 
in CM (e.g. some root solvers).]

> 2.       Because of the variation in functions I'm thinking that the 
> user
> should be able to select from a range of interpolators when they 
> generate
> their bi-cubic interpolation function.  What are the thoughts of the 
> default
> BicubicSplineInterpolator generating coefficients based on B-spline, 
> but
> giving users the option of generating with AkimaSplineInterpolator,
> SplineInterpolator (natural spline), or B-spline interpolator?

It sounds good. The actual API could be discussed once the 
is in place.

A possibility is to leave the current code alone (to be deprecated), 
create a completely new set of classes.

> 3.       I was thinking of also implementing a BiLinearInterpolator 
> and a
> BiCubicInterpolator, since those are less costly to analyze and for 
> certain
> datasets may be better behaved.


> 4.       Should I be generating JIRA issues for each of the 
> interpolator
> types or do any that correspond to fixing the 
> BicubicSplineInterpolator all
> fall into the one issue?

Please open several reports. Ideally (IMHO) an issue should deal with
each smallest independent change (or addition).

> This is my first contribution to the Apache Commons, so I apologize 
> if the
> answers to these questions is patently obvious to everyone else.

Welcome and thanks again for your interest in improving the library!

Best regards,

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

View raw message