[GiNaC-devel] release 1.3.6

Chris Dams Chris.Dams at mi.infn.it
Wed Dec 13 12:48:20 CET 2006


Dear Alexei,

On Tue, 12 Dec 2006, Sheplyakov Alexei wrote:

> +               static std::vector<numeric> coeffs_12; // Use in case Digits <= 20
> +               static std::vector<numeric> coeffs_30; // Use in case Digits <= 50
> +               static std::vector<numeric> coeffs_60; // Use in case Digits <= 100
> +               static std::vector<numeric> coeffs_120; // Use in case Digits <= 200
> 
> 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.
 
> +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. Therfore they are zero if this 
constructor is called for the first time.

> 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 otherwise I'm 
afraid that also the function PiEvalf will do the wrong thing.

> +       numeric result
> +                       = sqrt(numeric(2).mul(pi_val))
> +                               .mul(temp.power(x.add(numeric(-1,2))))
> +                               .mul(exp(temp.mul(-1)))
> +                               .mul(A);
> +
> 
> 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.

Best wishes,
Chris



More information about the GiNaC-devel mailing list