[GiNaC-devel] Re: numerical evaluation of tgamma and co [Was: release 1.3.6]

[Chris Dams]

Dear Alexei,

On Wed, 13 Dec 2006, Sheplyakov Alexei wrote:

> > > All these foo.mul(bar).add(baz) are plain ugly. Any objections
> > > against s/numeric/cl_N/g (so it is possible to use natural syntax)?
> > 
> > If that has infix operators, I would say it would be much nicer.
> 
> Sure, it has (like [almost] all CLN types). 

Okay, then I will do this as soon as I have some time.
 
> Secondly, it would be nice to remove artificial limit (Digits <= 200)
> and make the evaluation really arbitrary-precision. To do this one
> need to calculate missing coefficients at run-time and store them in 
> vector<vector <numeric> > (or vector<vector <cl_R> >).

Yes, but calculating these coefficients is rather demanding. I don't think
users will like it very much if evalfing their expressions, suddenly makes
their pogram allocate a few hundreds of MBs. Fortunately, these hundreds
of MBs are deallocated after that, but it still needs to fit next to the
memory of the application that the user is trying to run.  Actually, I do
not understand very well why it is so computationally intense. Maybe I
could try to make the intermediate integer coefficients floats, so that
they can be smaller? Not sure, maybe I will have a look at this.

> > > +lanczos_coeffs::lanczos_coeffs()
> > > +{      if (coeffs_12[0] != 0)
> > > +               return;
> > > 
> > > I think coeffs_12[0] might be not initialized at this stage (and
> > > contain random garbage).
> > 
> > No, that is not true. The elements of the vector have been constructed 
> > using the default constructor of numeric.
> 
> I think it is safer and simpler to add `static int count' so we don't
> ever run into yet another static order initailization problem.

Yes, there will be probs if someone starts doing evalfs of gamma functions 
at static initialization time. Okay, I think I will do as you suggest.

Best wishes,
Chris