You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Hank Grabowski <ha...@applieddefense.com> on 2014/10/07 20:27:52 UTC
[math] New 1D Interpolator By-Products
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. 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):
http://www.eol.ucar.edu/homes/granger/bspline/doc/
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?
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?
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?
This is my first contribution to the Apache Commons, so I apologize if the
answers to these questions is patently obvious to everyone else.
Thanks!
Hank Grabowski
Chief Technology Officer
10440 Little Patuxent Parkway, Suite 600
Columbia, MD 21044
(410) 715-0005 Office
(410) 715-0008 Fax
(301) 525-6219 Mobile
hank@applieddefense.com
www.AppliedDefense.com
Re: [math] New 1D Interpolator By-Products
Posted by Gilles <gi...@harfang.homelinux.org>.
Hello.
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):
>
> http://www.eol.ucar.edu/homes/granger/bspline/doc/
>
>
>
> 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
occurrences
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
functionality
is in place.
A possibility is to leave the current code alone (to be deprecated),
and
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.
Great.
> 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,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org