[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-gsl] GSL interpolation

From: Evgeny Kurbatov
Subject: Re: [Bug-gsl] GSL interpolation
Date: Fri, 27 Jul 2012 12:56:05 +0400

> > Hi, Jens!
> > 
> > I was the one who proposed a patch for interpolation routines
> > toughening control to the boundary violation. There was times when I
> > was sorry about that, but now the belief rises that this was right.
> > The control forces you to think deeper and be more accurate.
> > So hold on, be man!
> It certainly is very important to make sure extrapolation is not
> mistaken for interpolation. I absolutely agree that this is a good
> move! Still, [platform & compiler flag (fast-math) dependent] round
> off errors should not be making you have to dig into things.
> Certainly fixed this by manning up ;-)

You're right on the one hand but the tolerance value you're propose
fixates precision on some poorly controlled level. Why 1e-14, not
GSL_DBL_EPSILON? On the other hand, this tolerance may cause necessity
to make the range check in routines where the interpolation results are
used. Namely such a hardly to catch bug has led to the patch.
It's just my opinion.

> >> In addition, I was wondering if the GSL team could be interested in
> >> some pretty fast and accurate integration schemes based on the
> >> Patterson quadrature rules? These are fully nested and converge
> >> very rapidly. I have the required c++ code and will be happy to
> >> provide them. Certainly, this can only be a base for GSL, since
> >> you guys have much higher coding standards...
> > 
> > I don't mind.
> It is not my invention (just like Gauss-Kronrod is not yours), but it
> beats almost any quadrature rule! NAG uses it, and it is one of the
> most efficient algorithms I have come across. Just take a look. Even
> for me as an amateur programmer it did not take a lot to beat your
> integration routines & those of scipy in most cases [still getting
> precision to all digits]. It would be foolish not to consider these
> impressive methods. I am sure you will find all you need digging
> yourself then.

As for me I'm not a maintainer of GSL and didn't contribute to the
integration routines.
It would be easier for all, if you provide a code preferentially in a
plain C because of the architecture of GSL. But also send a C++
version, please.

> > Best witches,
> > Evgeny Kurbatov
> All the best & many thanks for your kind response,
> Jens

reply via email to

[Prev in Thread] Current Thread [Next in Thread]