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-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
