[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