commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles <gil...@harfang.homelinux.org>
Subject Re: [Math] MATH-1166
Date Tue, 25 Nov 2014 01:02:28 GMT
On Mon, 24 Nov 2014 09:35:23 -0500, Hank Grabowski wrote:
> I was pleasantly surprised to see that you got the coefficients and
> algorithms from that article working.  I'm surprised it was a 
> flipping of
> the coefficients.  When I re-implemented it in Octave a flipped 
> coefficient
> matrix caused for more havoc than the correctly oriented one.  The
> "correctly oriented" Octave one was producing the same results as the
> Apache Math implementation, the transpose far far worse.  Plus there 
> was a
> coefficient flip change in the previous release which addressed the
> accuracy issues.

Yes, I'm a bit worried that it looks like reverting to a
previous state, but it is perhaps the second problem (the
"delta" between sample points) that caused a additional bug
to look like an improvement...
It's Ajo's picture case that made me spot where the flip was.
The second problem did not cause a confusion in that case
because the "delta" is 1.

After fixing the two bugs, it took me much more time to figure
out that the points with low accuracy interpolation were all
along the borders of the sample grid. :-/

It would be good to have a way to provide good interpolation
also there, like your implementation does...

>  Either way it's clear that the new code is working based
> on the tight tolerances of the new test, which is great news.

It seems that that algorithm might in some cases produces a
smoother output (cf. link below).

> On the question of naming, this doesn't look piecewise to me.  Yes, 
> there
> are splines for each region rather trying to create an interpolation
> function for the entire region (which of course doesn't work).  
> However I
> look at mine as "piecewise" because I don't calculate two-dimensional
> coefficients but rather interpolate in one axis for several lines in 
> the
> second axis and then interpolate those results a second time.  Is 
> there a
> common name for the algorithm you implemented, like in the Akima 
> spline?

Here,
   http://www.giassa.net/?page_id=371
they call it "generalized bicubic interpolation".

> I'm fine with the existing chosen name for those objects if there 
> isn't a
> specific name.  It seems appropriate and descriptive.

I'm fine with the names too, then.

> For 3+ dimensional interpolation the good news is that the brute 
> force
> method I used can be extended pretty easily to higher dimensions.  It 
> is
> how I was planning on implementing Tricubic when I got time to work 
> on this
> again.  It works n-dimensionally because you just repeat that curve 
> fitting
> and sampling for as many dimensions as you like.  Rather than coding 
> up a
> Tricubic explicitly maybe we can just code up the n-dimensional 
> method
> instead.  The overhead of the generalization to more than three 
> dimensions
> shouldn't be dramatic.
> I hope to have more time after the beginning of next month to look at 
> this
> if you would like me to try to take a whack at it.

You are certainly welcome to do it.

Thanks,
Gilles


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


Mime
View raw message