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.