Re: GSL 2.0 roadmap (one man's view)

[Gerard Jungman <jungman at lanl dot gov>]

regarding error estimates in the special functions:

On Mon, 2009-09-07 at 13:13 +0100, Brian Gough wrote:
> 
> I have found the error estimates to be pretty useful when debugging,
> and they are only a small extra cost.

It's not about cycles. Nobody is counting cycles (yet).

It's about the intellectual cost of having all that junk in there. 
It takes up valuable real estate, makes it very difficult for
third party contributors to work with, and it is not based on
any rational methodology.

There is a long discussion about this on the mailing list,
from some years ago. It arose again recently. See the
archived thread starting with:
  http://sourceware.org/ml/gsl-discuss/2004-q3/msg00059.html


Now about cycles. Whether or not the cycle count shows a real
performance issue on current hardware is an open question. I'm
sure it depends on the details, and probably on hardware in
some cases.

But whether or not it is real, there is perceived problem.
See the comments in the above thread. Perceived problems
are real problems, when you are trying to expand the user base.


> Some of the hypergeometric functions are difficult to understand in
> places.  

I wrote them, and I find them nearly impossible to understand.
And I never use them; I would rather spend time finding a more
reliable solution in any specific circumstance. Eventually they
will be scrapped, or at least relegated to some closet in the
library where we store messy things.

As I have said before, having those functions living right
next door to gold-plated Bessel function implementations
is incongruous. This is a _real_ problem because it clouds
the issue of reliability for the whole module.


> Here it would be good to have an explicit higher-level
> version of the C implementation, for example in Maxima, that one could
> test against and understand more easily.

Maybe. If somebody wanted to do that. But it's never that simple.
That would only address some fraction of the possible problems;
the details would remain too different. A combination of methods
is needed.

The first real step would be to refactor so that all the commonality
in methods is better exposed. There are too many places where the
same continued fraction method or series summation method is
being applied, with only slight variation. But I digress.

--
G. Jungman