Re: specfunc error analysis - generated and propagated errors.

["Jonathan G. Underwood" <j dot underwood at open dot ac dot uk>]

Linas Vepstas wrote:

> backward error analysis might be just the right thing for the 
> "gold-plated" algorithms that Gerard refered to.   However,
> it makes me nervous in other cases e.g. the mentioned incomplete 
> gamma, where errors can go from tiny to huge for some small 
> changes in input parameters.  
>
> Besides, I'm guessing that *if* a good backward-analysis can 
> be done for an algo, then the algo can probably be fixed to 
> provide the 'gold-plated' answers.   :)
>
> Besides, "comparing known values of the functions to computed values" 
> is a sure-fire recipie for disaster, since users often explore paramter
> values that the authors didn't test for ... I still remember being burned
> by the NAG libraries, on bessel functions of high order, for which the 
> the output of the NAG algos resembled swiss cheese... 

Yes, of course, a function by function analysis would be needed, and 
we'd have to ensure the whole useable domain was checked. It _should_ be 
possible for most functions to implement backward error analysis, 
referring characterization of the error analysis to the test suite, 
rather than the specfunc code base. I think at this point, what's 
actually needed is to do some testing, which I'll look into doing when I 
next have time.

> > > returned by the _e functions. 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.
>
>
> I don't get it ... there is a 'simple' technical fix to this, 
> by using some c pre-prossesor macro magic.  You can have
> your cake and eat it too.  Compile functions with and without
> error esitmates from the same source code base, and then use
> macro magic to define two different subroutine names, one for each
> version.

<snip>

Yep, this is a really nice way of removing the overhead of error 
approximation when we don't need it. I prefer it greatly to Brian's 
suggestion of recompiling the library - clearly not a user friendly 
approach. Note that this problem though is distinct from the problem of 
whether or not to replace forward error analysis with backwards error 
analysis. It might be nice to fix up the current code with this 
"preprocessor magic" as a first step though.

Jonathan