[Axiom-developer] RE: special functions

[Bill Page]

Yigal,

I think it is best if we try to keep the discussion on the
email lists (either axiom-developer or axiom-math) so that
other people can contribute.

On January 30, 2006 3:57 PM you wrote:
> 
> 1.  Your code in the SandBox does not allow for gamma(0,x),
> i.e. where a=0 (the link for some reason is down right now
> so perhaps you have changed things a bit but this is from
> viewing it yesterday).

There is an intermitant problem with the server. It should be
working now. I think the case of a=0 is handled correctly.

> 
> 2.  To not use the symbolic capabilities of Axiom to 
> numerically compute Gamma seams quite a waste.

I am not quite sure what you mean by "use symbolic capabilities
to numerically compute"? This phrase does not seem to make sense
to me. Could you please explain?

> The continued fraction in equation 6.2.7 in NR is based upon
> 100s of years of work.  NR creates a good algorithm however my
> understanding is that a CAS can simply do more than a Fortran,
> or C numerical cranking code program.

No, I don't think so. Numerical evaluation is the same whether
it is done in Fortran or in SPAD. Actually the word "numerical"
is often miss-used. Really the distinction is between "exact"
and "approximate". Computer algebra systems (CAS) are designed
to be good at exact or symbolic computation but can usually also
do various kinds of approximate or numeric calculation. Fortran
is not so good at symbolic computation, but it is possible.

Perhaps to over state this issue a little: Really there is no
such thing as numeric computation (except perhaps for the
analog simulation engines which are very little used today).
All computation on a digital computer is symbolic by it's very
nature. What we call "numeric" is really just a very specialize
kind of symoblic calculation that is especially suited to
approximate calculations that take account of the technical
limitations of the hardware (memory and word size).

> This is why I spent time creating a c-fraction for this
> function.  So why recreate what has already been done.  

But the code from NR *does* use the continued fraction
method of evaluation the incomplete gamma function!

Axiom's ContinueFraction domain is something else. It's
purpose is to represent a continued fraction in it's full
*exact* infinite form. That's why it is specified in terms
of Streams (infinite lists). Of course this does not mean that
we need infinite memory. Instead what we have is an algorithm
that can produce as many aproximants as we desire and/or have
time and memory available. What you were writing is not a
numerical method, it is really a method for the *exact*
representation of the incomplete Gamma function.

You should read especially the section in the Axiom book
section 9.12 (page 498) about ContinuedFraction. It is important
to understand in what sense the continued fraction:

z := continuedFraction(3,repeating [1],repeating [3,6])

represents sqrt(11) *exactly*. In principle it is possible to
define exactly what one means by

  z*z = continuedFraction(11)

symbolically (exactly). Similarly you could take your
continuedFraction expression for gamma(a,x) and then

  z*gamma(1,2)

is an exact expression.

Then from such exact expressions one can extract the desired
approximant as needed.

All of this is only "in principle" however because Axiom's
ContinuedFraction domain has some serious limitations.

Also, there are some other methods besides continued fractions
that might be a better representation for exact reals.

> 
> 3.  That is can't Axiom feed gfortran (I am a linux user) etc.
> a code and it can do that dirty work- even using GMP to get
> arbitrary precision.

Axiom already uses GMP.

> Axiom should be able to do other tasks like first symbolically
> calculate a function use it in a symbolic calculation,
> convert the fraction to another one etc. and find the nth
> order convergent symbolically and then feed other programs
> the numerical work. This is my feeling.  

I agree with your feeling, but I am not entirely sure how to
put it into practice.

> 
> Fortran, C, etc. have had so many man hours spent trying to
> make them extremely good at computing that it seams only fair
> to use them and to work on tasks that they simply cannot perform -
> symbolic manipulations.    
> 

As I said above, I think that is not "exactly" true. :)

Regards,
Bill Page.