I ran a C version of the example and it worked and gave -1 for the value. I'll cook up a simple test case to add to our test suite for use in debugging the problem. If you see what is wrong with the current gsl_interp.pd code, patches are definitely welcome---and get fixes released sooner.
Thanks for the report, Chris On Thu, Feb 9, 2012 at 8:16 PM, chm <[email protected]> wrote: > Hmm. Ok. So much for the quick fix. > > I did not think that a cspline fit was > valid for the GSL interp eval routine. > I guess someone who can check against the > actual GSL interp routine results can show > what the correct value should be. > > Sorry I couldn't be more helpful. > > --Chris > > > On 2/9/2012 7:57 PM, InSuk Joung wrote: >> >> Hi, >> Thank you for the reply. Anyway, it should not be an exception. The >> correct >> answer of the test code should be -1 not nan. At least, that's the number >> I >> get from v2.4.6. >> >> On Thu, Feb 9, 2012 at 7:37 PM, chm<[email protected]> wrote: >> >>> On 2/9/2012 6:01 PM, InSuk Joung wrote: >>> >>>> use strict; >>>> use warnings; >>>> use PDL; >>>> use PDL::GSL::INTERP; >>>> >>>> my $x = sequence(10); >>>> my $y = $x**2; >>>> >>>> my $spl = PDL::GSL::INTERP->init( 'cspline', $x, $y ); >>>> print $spl->eval( -1, {Extrapolate=>1} ), "\n"; >>>> >>> >>> The problem with the exception handler appears >>> to have been fixed since the PDL-2.4.7 release >>> (according to the git log). To avoid the problem >>> you'll need to avoid out-of-domain values for the >>> input parameter being evaluated or switch to PDL >>> version 2.4.8 or newer (the PDL-2.4.10 release >>> this week has many bugs fixed and new features!). >>> I ran your test code on 2.4.10 and the result >>> was nan with no error as expected. >>> >>> --Chris >>> >> >> >> > _______________________________________________ Perldl mailing list [email protected] http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
