This is the mail archive of the gsl-discuss@sources.redhat.com mailing list for the GSL project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: GSL -- sphPlm_deriv


On Mon, 2002-11-11 at 06:45, rainer.bunger@m.eads.net wrote:

> Is it true that the problems with divergent derivative
> disappear in the derivative with respect of \theta?

Yes. I believe that the factor of d(cos(theta))/dx
automatically regulates the functions in all cases.


> Sorry for the problems caused. But I think some people will find it useful 
> to have the current derivative in the GSL.

You should be able to use them too. I realize now what you want.
A few factors of sqrt(1 - x^2) and a test for x==1.0 are an
annoyance from your point of view, but I hope it doesn't prevent
you from using them. If there is really a robustness issue,
that could be a real problem, but nothing that a little hacking
at the implementation won't fix.


Your questions raise an interesting point. The standard math
reference literature considers these as functions of x, but
clearly the geometric nature (in the final analysis this arises
from the group theoretical significance of the functions)
makes theta=acos(x) a very simple choice, both from the
standpoint of function properties and of numerical simplicity
due to the built-in regularity.

I made an explicit choice to use 'x' as the independent
variable because if I used theta then people who needed
things as a function of x would have to insert invocations
of cos() in various places (and maybe even acos(), blechh...).
A similar thing happens for Chebyshev polynomials.

But it is clear that this choice involves a trade-off.

Ideally one wants a framework where both possibilities
are supported in a natural way. This becomes an issue
for the implementation because I don't want to have
a bunch of separate implementations for recursions, etc.
This is already a problem for the sphPlm() functions,
where the implementation is basically independent of
that for the Plm() functions. I hate that sort of
disorganization. Perhaps the Plm()'s should be
implemented in terms of the sphPlm()'s; but that's
not the way it turned out.

The associated mathematical question is how to identify
the "geometrically natural" independent variable for
the other functions with group-theoretical significance.
In some cases it is not so obvious which choice is "correct".

Then the question for the implementor is how to support
the various choices in the most elegant way.

If anybody has any thoughts on this, let me know.
It might not be too hard to straighten all this
out, but I haven't had much time to think about
this sort of thing lately.

-- 
Gerard Jungman <jungman@lanl.gov>
Los Alamos National Laboratory


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]