[GiNaC-devel] release 1.3.6

Sheplyakov Alexei varg at theor.jinr.ru
Tue Dec 12 18:01:41 CET 2006


On Tue, Dec 12, 2006 at 05:45:36PM +0100, Jens Vollinga wrote:
> Dear all,
> 
> I am about to release 1.3.6 this evening (or later ... ;-) ). Please 
> have a look at the NEWS file and the last minute submissions I did and 
> tell me if you find something missing or wrong.
> 
> @Alexei: I had to apply two of your patches manually, because the format 
> was somehow broken. I hope I did everything correctly.

There is no need for doing useless job. Feel free to ask me to re-send
the patch[es] if you need.

> @Richy: I'd like to include Chris' numerical evaluation of tgamma and 
> friends. It's just another class added, so I think it is okay to be 
> included because the ABI doesn't change. But because of bad experience 
> in the past I'd like to ask you again to be sure.

+class lanczos_coeffs
+{
+       public:
+               lanczos_coeffs();
+               bool sufficiently_accurate(int digits);
+               int get_order() const { return current_vector->size(); }
+               numeric calc_lanczos_A(const numeric &) const;
+       private:
+               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?

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

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?

+       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)?


Best regards,
 Alexei

-- 
All science is either physics or stamp collecting.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 827 bytes
Desc: Digital signature
URL: <http://www.ginac.de/pipermail/ginac-devel/attachments/20061212/da399d1f/attachment.sig>


More information about the GiNaC-devel mailing list