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