Re: specfunc error analysis - generated and propagated errors.

[C J Kenneth Tan -- OptimaNumerics <cjtan at OptimaNumerics dot com>]

Hi Brian,

I wonder what your view may be, about code running on supercomputers.
Will you still recommend the approach of Gottbrath et al?  


Best wishes,
Ken
-----------------------------------------------------------------------
C. J. Kenneth Tan, Ph.D.
OptimaNumerics Ltd.
E-mail: cjtan@OptimaNumerics.com      Telephone: +44 798 941 7838    
Web: http://www.OptimaNumerics.com    Facsimile: +44 289 066 3015 
-----------------------------------------------------------------------




On 2004-09-10 20:58 +0100 Brian Gough (bjg@network-theory.co.uk) wrote:

> Date: Fri, 10 Sep 2004 20:58:44 +0100
> From: Brian Gough <bjg@network-theory.co.uk>
> To: gsl-discuss@sources.redhat.com
> Subject: Re: specfunc error analysis - generated and propagated errors.
> 
> Jonathan G. Underwood writes: 
>  > It would make for a much cleaner design of the specfun code, and
>  > also remove the runtime computational overhead of (most-times often
>  > unused) the forward error analysis.
> 
> If a foo_e function was eating a lot of time in my application, I
> would tweak GSL by declaring it "extern inline". The calculation of
> the error estimate would then drop out of the corresponding foo
> function (by data flow analysis).  
> 
> I think this basically does what you want.  If the function is large,
> you might need to increase GCC's limit on inlined function size.
> 
> For those concerned with peformance, I commend the approach of
> Gottbrath et al, http://arxiv.org/abs/astro-ph/9912202.
> 
> -- 
> Brian Gough
> 
> 
>