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

Sheplyakov Alexei varg at theor.jinr.ru
Wed Dec 13 20:16:14 CET 2006


Hi, Chris!

> > const numeric lgamma(const numeric &x)
> > {
> > -       throw dunno();
> > +       lanczos_coeffs lc;
> > +       if (lc.sufficiently_accurate(Digits)) {
> > +               numeric pi_val(cln::pi(cln::default_float_format));
> > 
> > What happens here if Digits > default_float_format?
> 
> I sincerely hope that it won't cause problems

... because it is impossible:

/** Assign a native long to global Digits object. */
_numeric_digits& _numeric_digits::operator=(long prec)
{
	digits = prec;
	cln::default_float_format = cln::float_format(prec); 
	return *this;
}

Sorry for the noise.

> > 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). 

> > With such a code one need to break ABI (add extra class members) in
> > order to increase the precision. May be replacing all these with
> > static std::vector<std::vector<numeric> >  would be better solution?
> 
> Richy has already answered this.

I think his answer is wrong.

Leaving aside the ABI, I don't think adding more members to a class
to achive better precision is a good idea anyway.

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> >).

> > +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.

Best regards,
 Alexei

-- 
All science is either physics or stamp collecting.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: Digital signature
Url : http://www.cebix.net/pipermail/ginac-devel/attachments/20061213/655e053c/attachment.pgp


More information about the GiNaC-devel mailing list