From kreckel at ginac.de Sun Dec 3 18:47:23 2006 From: kreckel at ginac.de (Richard B. Kreckel) Date: Sun, 03 Dec 2006 18:47:23 +0100 Subject: [GiNaC-devel] [PATCH] gcd: fix heuristics to chose main variable properly In-Reply-To: <20061120190140.GA19168@theor.jinr.ru> References: <20061120190140.GA19168@theor.jinr.ru> Message-ID: <45730DAB.5050003@ginac.de> Alexei Sheplyakov wrote: >Heuristic code in gcd [very] often makes bad choice of the main variable. >In particular, if one of polynomials (say, p2) does not contain >the variable x which _is contained_ in another one (say, p1), than >gcd(p1, p2) will use such a variable as a main, so subsequent calculation >becomes unnecessary complicated. Fixing this substantially improves worst >case performance (less than minute versus infinity). > > I've just applied your patch to the main branch. Thanks. -richy. -- Richard B. Kreckel From Chris.Dams at mi.infn.it Fri Dec 8 17:51:24 2006 From: Chris.Dams at mi.infn.it (Chris Dams) Date: Fri, 8 Dec 2006 17:51:24 +0100 (CET) Subject: [GiNaC-devel] Numerical evaluation for tgamma, lgamma and beta. Message-ID: Dear all, I added numerical evaluation for the functions tgamma, lgamma and beta to the CVS. The method employed is the Lanczos approximation as described on Wikepedia: http://en.wikipedia.org/wiki/Lanczos_approximation . (I also corrected some small errors on that page.) This method uses a fixed precision and tables are used to store coefficients. Currently the tables available are for maximally 20, 50, 100 and 200 digits. If Digits exceeds 200, no numerical evaluation is available. Best wishes, Chris From vollinga at physik.uni-wuppertal.de Fri Dec 8 17:55:30 2006 From: vollinga at physik.uni-wuppertal.de (Jens Vollinga) Date: Fri, 08 Dec 2006 17:55:30 +0100 Subject: [GiNaC-devel] Upcoming release Message-ID: <45799902.4050500@physik.uni-wuppertal.de> Dear all, due to a newly discovered bug in the numerical evaluation of multiple polylogs I feel the strong urge to do a new GiNaC release very soon. Are there any unresolved issues or pending submissions that call for a delay of this release beyond the oncoming Monday? Regards, Jens From varg at theor.jinr.ru Fri Dec 8 19:35:19 2006 From: varg at theor.jinr.ru (Sheplyakov Alexei) Date: Fri, 8 Dec 2006 21:35:19 +0300 Subject: [GiNaC-devel] Upcoming release In-Reply-To: <45799902.4050500@physik.uni-wuppertal.de> References: <45799902.4050500@physik.uni-wuppertal.de> Message-ID: <20061208183519.GA4659@theor.jinr.ru> Hi! On Fri, Dec 08, 2006 at 05:55:30PM +0100, Jens Vollinga wrote: > Dear all, > > due to a newly discovered bug in the numerical evaluation of multiple > polylogs I feel the strong urge to do a new GiNaC release very soon. Do you mean bugfix-only release (1.3.6)? > Are there any unresolved issues or pending submissions that call for a > delay of this release beyond the oncoming Monday? It would be nice if my patches for gcd() (http://www.ginac.de/pipermail/ginac-devel/2006-November/001087.html, already included into 1.4 branch) and basic::collect() (http://www.ginac.de/pipermail/ginac-devel/2006-November/001092.html) get included. Secondly, there is also minor bugfix for tensor::replace_contr_index(): http://www.ginac.de/pipermail/ginac-devel/2006-October/001068.html 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: From Chris.Dams at mi.infn.it Mon Dec 11 10:44:37 2006 From: Chris.Dams at mi.infn.it (Chris Dams) Date: Mon, 11 Dec 2006 10:44:37 +0100 (CET) Subject: [GiNaC-devel] Bugfix for numerical integration. Message-ID: Dear all, I discovered that the numerical integration routine that I wrote does not handle complex functions. The inequalities in the error checking are the problem. Therefore, I added some abs-function to the code. BTW, maybe it would be a good idea to include the numerical evalution for the gamma function that I comitted last friday in 1.3 as well? Maybe it could also go into release today? Bye, Chris From kreckel at ginac.de Mon Dec 11 12:10:08 2006 From: kreckel at ginac.de (Richard B. Kreckel) Date: Mon, 11 Dec 2006 12:10:08 +0100 Subject: [GiNaC-devel] Bugfix for numerical integration. In-Reply-To: References: Message-ID: <457D3C90.3080402@ginac.de> Chris, Chris Dams wrote: >BTW, maybe it would be a good idea to include the numerical evalution for >the gamma function that I comitted last friday in 1.3 as well? Maybe it >could also go into release today? > > Is there a reason why didn't you hook up your numerical evaluation to the eval functions? I think users will find this behavior slightly irritating: > sin(3.141592000); 6.53589793238438481E-7 > tgamma(3.141592000); tgamma(3.141592) > evalf(%); 2.2880363339786210185 Cheers -richy. -- Richard B. Kreckel From kreckel at ginac.de Mon Dec 11 12:13:07 2006 From: kreckel at ginac.de (Richard B. Kreckel) Date: Mon, 11 Dec 2006 12:13:07 +0100 Subject: [GiNaC-devel] Upcoming release In-Reply-To: <45799902.4050500@physik.uni-wuppertal.de> References: <45799902.4050500@physik.uni-wuppertal.de> Message-ID: <457D3D43.1020604@ginac.de> Jens Vollinga wrote: > due to a newly discovered bug in the numerical evaluation of multiple > polylogs I feel the strong urge to do a new GiNaC release very soon. > > Are there any unresolved issues or pending submissions that call for a > delay of this release beyond the oncoming Monday? Too late, Debian/etch has been frozen a few minutes ago... Seriously: may I invite people who committed patches to uptdate the NEWS file a bit? We are too laze to maintain a ChangeLog, but the NEWS file is quite helpful. Regards -richy. -- Richard B. Kreckel From Chris.Dams at mi.infn.it Mon Dec 11 13:55:08 2006 From: Chris.Dams at mi.infn.it (Chris Dams) Date: Mon, 11 Dec 2006 13:55:08 +0100 (CET) Subject: [GiNaC-devel] Bugfix for numerical integration. In-Reply-To: <457D3C90.3080402@ginac.de> Message-ID: Dear Richy, On Mon, 11 Dec 2006, Richard B. Kreckel wrote: > Is there a reason why didn't you hook up your numerical evaluation to > the eval functions? I think users will find this behavior slightly > irritating: I guess, because I missed the comments that asked me to do so ;-). I now fixed this in CVS. Best, Chris From vollinga at physik.uni-wuppertal.de Tue Dec 12 12:57:35 2006 From: vollinga at physik.uni-wuppertal.de (Jens Vollinga) Date: Tue, 12 Dec 2006 12:57:35 +0100 Subject: [GiNaC-devel] New bug in symmetrization? Message-ID: <457E992F.3030907@physik.uni-wuppertal.de> Hi, 'make check' gives me a failure for the paranoia exam number 17. That exam is concerned with the symmetrization of indices. Can anybody reproduce that finding? It didn't fail before I did an cvs update (my local version was rather old), so either the bug must be really new or it is one of the bugs that appear only when the ordering of expressions is disadvantageous due to the memory layout. Regards, Jens From Chris.Dams at mi.infn.it Tue Dec 12 14:07:42 2006 From: Chris.Dams at mi.infn.it (Chris Dams) Date: Tue, 12 Dec 2006 14:07:42 +0100 (CET) Subject: [GiNaC-devel] New bug in symmetrization? In-Reply-To: <457E992F.3030907@physik.uni-wuppertal.de> Message-ID: Dear Jens, On Tue, 12 Dec 2006, Jens Vollinga wrote: > 'make check' gives me a failure for the paranoia exam number 17. That > exam is concerned with the symmetrization of indices. > > Can anybody reproduce that finding? HEAD or 1.3? At my place (an AMD64) both checks and exams for both HEAD and 1.3 run just fine. If behaviour depends on canonical ordering, I think that is bad and it needs to be fixed. Best, Chris From varg at theor.jinr.ru Tue Dec 12 14:15:31 2006 From: varg at theor.jinr.ru (Alexei Sheplyakov) Date: Tue, 12 Dec 2006 16:15:31 +0300 Subject: [GiNaC-devel] New bug in symmetrization? In-Reply-To: <457E992F.3030907@physik.uni-wuppertal.de> References: <457E992F.3030907@physik.uni-wuppertal.de> Message-ID: <20061212131531.GA15734@theor.jinr.ru> Dear Jens, > 'make check' gives me a failure for the paranoia exam number 17. That > exam is concerned with the symmetrization of indices. > > Can anybody reproduce that finding? I can't reproduce this. > It didn't fail before I did an cvs update (my local version was rather > old), This check is rather new (to be more specific, it was added on Oct 20). Could you check if it really existed in your old version? > so either the bug must be really new or it is one of the bugs that > appear only when the ordering of expressions is disadvantageous due to > the memory layout. I admit this might be some new bug, but... Could you please re-check if your local copy of the `indexed.cpp' file is really up-to-date? 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: From vollinga at physik.uni-wuppertal.de Tue Dec 12 14:17:49 2006 From: vollinga at physik.uni-wuppertal.de (Jens Vollinga) Date: Tue, 12 Dec 2006 14:17:49 +0100 Subject: [GiNaC-devel] New bug in symmetrization? In-Reply-To: References: Message-ID: <457EABFD.9050605@physik.uni-wuppertal.de> Hi Chris, Chris Dams schrieb: > HEAD or 1.3? At my place (an AMD64) both checks and exams for both HEAD > and 1.3 run just fine. If behaviour depends on canonical ordering, I think > that is bad and it needs to be fixed. it's 1.3. I forgot to mention in one of my last mails to write that the new release will be just a maintenance release 1.3.6. So, the Debian guys don't have to delay their release because of us. Lucky them. Regards, Jens From vollinga at physik.uni-wuppertal.de Tue Dec 12 14:55:27 2006 From: vollinga at physik.uni-wuppertal.de (Jens Vollinga) Date: Tue, 12 Dec 2006 14:55:27 +0100 Subject: [GiNaC-devel] New bug in symmetrization? In-Reply-To: <457EABFD.9050605@physik.uni-wuppertal.de> References: <457EABFD.9050605@physik.uni-wuppertal.de> Message-ID: <457EB4CF.6030002@physik.uni-wuppertal.de> Hi Chris and Alexei, now after a totally fresh checkout the error is gone ... Sorry to have caused false alarm. BTW, the error didn't go away after I had deleted and re-checked out indexed.{h,cpp}. Makes me wonder about the (auto)configure system, though. Regards, Jens From vollinga at physik.uni-wuppertal.de Tue Dec 12 17:45:36 2006 From: vollinga at physik.uni-wuppertal.de (Jens Vollinga) Date: Tue, 12 Dec 2006 17:45:36 +0100 Subject: [GiNaC-devel] release 1.3.6 Message-ID: <457EDCB0.40701@physik.uni-wuppertal.de> 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. @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. Regards, Jens From varg at theor.jinr.ru Tue Dec 12 18:01:41 2006 From: varg at theor.jinr.ru (Sheplyakov Alexei) Date: Tue, 12 Dec 2006 20:01:41 +0300 Subject: [GiNaC-devel] release 1.3.6 In-Reply-To: <457EDCB0.40701@physik.uni-wuppertal.de> References: <457EDCB0.40701@physik.uni-wuppertal.de> Message-ID: <20061212170140.GA11136@theor.jinr.ru> 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 coeffs_12; // Use in case Digits <= 20 + static std::vector coeffs_30; // Use in case Digits <= 50 + static std::vector coeffs_60; // Use in case Digits <= 100 + static std::vector 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 > 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: From varg at theor.jinr.ru Tue Dec 12 18:07:56 2006 From: varg at theor.jinr.ru (Sheplyakov Alexei) Date: Tue, 12 Dec 2006 20:07:56 +0300 Subject: [GiNaC-devel] release 1.3.6 In-Reply-To: <20061212170140.GA11136@theor.jinr.ru> References: <457EDCB0.40701@physik.uni-wuppertal.de> <20061212170140.GA11136@theor.jinr.ru> Message-ID: <20061212170756.GA16732@theor.jinr.ru> > > @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. The patch addressing some of issues I've pointed out is available here: http://theor.jinr.ru/~varg/0001-lanczos_coeffs-fix-several-implementation-deficiencies.txt.gz [Mailing list software rejects it due to the size] 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: From varg at theor.jinr.ru Tue Dec 12 18:50:01 2006 From: varg at theor.jinr.ru (Sheplyakov Alexei) Date: Tue, 12 Dec 2006 20:50:01 +0300 Subject: [GiNaC-devel] release 1.3.6 In-Reply-To: <457EDCB0.40701@physik.uni-wuppertal.de> References: <457EDCB0.40701@physik.uni-wuppertal.de> Message-ID: <20061212175001.GA17828@theor.jinr.ru> On Tue, Dec 12, 2006 at 05:45:36PM +0100, Jens Vollinga wrote: > 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. diff --git a/NEWS b/NEWS index af36279..c8154e2 100644 --- a/NEWS +++ b/NEWS @@ -7,6 +7,7 @@ This file records noteworthy changes. * Fixed bug in numerical evaluation of multiple polylogs. * Fixed numerical integration of complex functions. * Fixed bug in tensor::replace_contr_index(). +* Fixed bug in reposition_dummy_indices(). 1.3.5 (17 August 2006) * Re-built bison related files that caused bugs with gcc 4. > @Alexei: I had to apply two of your patches manually, because the format > was somehow broken. I hope I did everything correctly. I'm little bit busy now, could you please wait till tomorrow? 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: From vollinga at physik.uni-wuppertal.de Tue Dec 12 18:52:43 2006 From: vollinga at physik.uni-wuppertal.de (Jens Vollinga) Date: Tue, 12 Dec 2006 18:52:43 +0100 Subject: [GiNaC-devel] release 1.3.6 In-Reply-To: <20061212175001.GA17828@theor.jinr.ru> References: <457EDCB0.40701@physik.uni-wuppertal.de> <20061212175001.GA17828@theor.jinr.ru> Message-ID: <457EEC6B.5050807@physik.uni-wuppertal.de> Hi Alexei, Sheplyakov Alexei schrieb: > I'm little bit busy now, could you please wait till tomorrow? okay. I will wait (as long as it takes). Regards, Jens From kreckel at ginac.de Tue Dec 12 21:26:59 2006 From: kreckel at ginac.de (Richard B. Kreckel) Date: Tue, 12 Dec 2006 21:26:59 +0100 Subject: [GiNaC-devel] release 1.3.6 In-Reply-To: <457EDCB0.40701@physik.uni-wuppertal.de> References: <457EDCB0.40701@physik.uni-wuppertal.de> Message-ID: <457F1093.9070601@ginac.de> Jens Vollinga wrote: > @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. The goal with the branch releases has always been to be strictly binary compatible. Updating the library underneath a program linked against it should not render the program unusable. Linux distributors rely on this when building library packages. The patch by Chris does clearly not change any public interface that might be used by an application. Regards -richy. -- Richard B. Kreckel From kreckel at ginac.de Tue Dec 12 21:34:57 2006 From: kreckel at ginac.de (Richard B. Kreckel) Date: Tue, 12 Dec 2006 21:34:57 +0100 Subject: [GiNaC-devel] release 1.3.6 In-Reply-To: <20061212170140.GA11136@theor.jinr.ru> References: <457EDCB0.40701@physik.uni-wuppertal.de> <20061212170140.GA11136@theor.jinr.ru> Message-ID: <457F1271.2080303@ginac.de> Sheplyakov Alexei wrote: >+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 coeffs_12; // Use in case Digits <= 20 >+ static std::vector coeffs_30; // Use in case Digits <= 50 >+ static std::vector coeffs_60; // Use in case Digits <= 100 >+ static std::vector 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 > would be better solution? > > But if the extra class members are of a class that is not intended to be used by any user of the library and cannot be used (at least without messing around), then it is okay. Chris was careful enough to add the class to file numeric.cpp, not to any of our header files. So it is not something anybody can use when linking his/her apps. Hence, there isn't anything that can break when the library is later upgraded underneath applications using it. Regards -richy. -- Richard B. Kreckel From varg at theor.jinr.ru Wed Dec 13 08:23:56 2006 From: varg at theor.jinr.ru (Sheplyakov Alexei) Date: Wed, 13 Dec 2006 10:23:56 +0300 Subject: [GiNaC-devel] release 1.3.6 In-Reply-To: <457F1271.2080303@ginac.de> References: <457EDCB0.40701@physik.uni-wuppertal.de> <20061212170140.GA11136@theor.jinr.ru> <457F1271.2080303@ginac.de> Message-ID: <20061213072356.GA4665@theor.jinr.ru> On Tue, Dec 12, 2006 at 09:34:57PM +0100, Richard B. Kreckel wrote: > But if the extra class members are of a class that is not intended to be > used by any user of the library and cannot be used (at least without > messing around), There is no need of "messing around". Corresponding symbols are readily available in the shared object (since they have ELF visibility `default' rather than `hidden' or `private'), so: // bugme.cpp #include namespace GiNaC { class lanczos_coeffs; } void foo() { using namespace GiNaC; lanczos_coeffs bugme; // do something here } BTW, people *do use* _exN stuff in their code. > Hence, there isn't anything that can break when the library is later > upgraded underneath applications using it. I don't think that changing class layout for increasing precision is a good idea anyway. 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: From varg at theor.jinr.ru Wed Dec 13 09:04:55 2006 From: varg at theor.jinr.ru (Sheplyakov Alexei) Date: Wed, 13 Dec 2006 11:04:55 +0300 Subject: [GiNaC-devel] release 1.3.6 In-Reply-To: <457EEC6B.5050807@physik.uni-wuppertal.de> References: <457EDCB0.40701@physik.uni-wuppertal.de> <20061212175001.GA17828@theor.jinr.ru> <457EEC6B.5050807@physik.uni-wuppertal.de> Message-ID: <20061213080455.GA9517@theor.jinr.ru> Hello, Jens! > @Alexei: I had to apply two of your patches manually, because the format > was somehow broken. I hope I did everything correctly. Yes, modulo minor whitespace damage :) > >I'm little bit busy now, could you please wait till tomorrow? > > okay. I will wait (as long as it takes). I've found yet another bug (seems to be fixed in HEAD): #include #include #include using namespace std; using namespace GiNaC; int main(int argc, char** argv) { idx a(symbol("a"), 8), b(symbol("b"), 8), c(symbol("c"), 8), d(symbol("d"), 8), e(symbol("e"), 8), f(symbol("f"), 8); ex H1 = color_f(a, c, e)*color_f(b, d, e) + color_f(a, d, e)*color_f(b, c, e); ex test = (H1*H1).expand(expand_options::expand_indexed); cout << test << endl; // 2*f.e.b.d*f.e.b.c*f.e.a.c*f.e.a.d+f.symbol8.b.c*f.symbol8.a.d*f.e.b.c*f.e.a.d+f.symbol7.b.d*f.symbol7.a.c*f.e.b.d*f.e.a.c // inconsistent indices! cout << test.simplify_indexed() << endl; // prints 288, should be 216 return 0; } I wonder if it is possible to backport the fix... 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: From varg at theor.jinr.ru Tue Dec 12 13:44:44 2006 From: varg at theor.jinr.ru (Alexei Sheplyakov) Date: Tue, 12 Dec 2006 15:44:44 +0300 Subject: [GiNaC-devel] Numerical evaluation for tgamma, lgamma and beta. In-Reply-To: References: Message-ID: <20061212124444.GA14986@pc7135.jinr.ru> Hello, On Fri, Dec 08, 2006 at 05:51:24PM +0100, Chris Dams wrote: > > Dear all, > > I added numerical evaluation for the functions tgamma, lgamma and beta to > the CVS. The method employed is the Lanczos approximation as described on > Wikepedia: http://en.wikipedia.org/wiki/Lanczos_approximation . (I also > corrected some small errors on that page.) > > This method uses a fixed precision and tables are used to store > coefficients. Currently the tables available are for maximally 20, 50, 100 > and 200 digits. If Digits exceeds 200, no numerical evaluation is > available. +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 coeffs_12; // Use in case Digits <= 20 + static std::vector coeffs_30; // Use in case Digits <= 50 + static std::vector coeffs_60; // Use in case Digits <= 100 + static std::vector 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 > (see attached patch) 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: 0001-lanczos_coeffs-fix-several-implementation-deficiencies.txt.gz Type: application/octet-stream Size: 40445 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: Digital signature URL: From vollinga at physik.uni-wuppertal.de Wed Dec 13 12:29:54 2006 From: vollinga at physik.uni-wuppertal.de (Jens Vollinga) Date: Wed, 13 Dec 2006 12:29:54 +0100 Subject: [GiNaC-devel] release 1.3.6 In-Reply-To: <20061213080455.GA9517@theor.jinr.ru> References: <457EDCB0.40701@physik.uni-wuppertal.de> <20061212175001.GA17828@theor.jinr.ru> <457EEC6B.5050807@physik.uni-wuppertal.de> <20061213080455.GA9517@theor.jinr.ru> Message-ID: <457FE432.6020806@physik.uni-wuppertal.de> Hi, Sheplyakov Alexei schrieb: > I've found yet another bug (seems to be fixed in HEAD): > I wonder if it is possible to backport the fix... that is fixed by the Oct 20th patch in HEAD, isn't it? That is hard to backport ... Does the inclusion of a friend class declaration in a class change its ABI? Regards, Jens From Chris.Dams at mi.infn.it Wed Dec 13 12:48:20 2006 From: Chris.Dams at mi.infn.it (Chris Dams) Date: Wed, 13 Dec 2006 12:48:20 +0100 (CET) Subject: [GiNaC-devel] release 1.3.6 In-Reply-To: <20061212170140.GA11136@theor.jinr.ru> Message-ID: Dear Alexei, On Tue, 12 Dec 2006, Sheplyakov Alexei wrote: > + static std::vector coeffs_12; // Use in case Digits <= 20 > + static std::vector coeffs_30; // Use in case Digits <= 50 > + static std::vector coeffs_60; // Use in case Digits <= 100 > + static std::vector 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 > 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 From Chris.Dams at mi.infn.it Wed Dec 13 12:57:25 2006 From: Chris.Dams at mi.infn.it (Chris Dams) Date: Wed, 13 Dec 2006 12:57:25 +0100 (CET) Subject: [GiNaC-devel] release 1.3.6 In-Reply-To: <20061213072356.GA4665@theor.jinr.ru> Message-ID: Dear Alexei, On Wed, 13 Dec 2006, Sheplyakov Alexei wrote: > // bugme.cpp > #include > namespace GiNaC { > class lanczos_coeffs; > } > > void foo() { > using namespace GiNaC; > lanczos_coeffs bugme; > // do something here > } The compiler says: "error: aggregate GiNaC::lanczos_coeffs bugme has incomplete type and cannot be defined". Hence, users would have to import the entire definition of this class from the file numeric.cpp. I think in that case they should know that they are doing something non-standard that can break at any time. If this is the only problem with it, I would not worry too much. Best wishes, Chris From Chris.Dams at mi.infn.it Wed Dec 13 13:13:54 2006 From: Chris.Dams at mi.infn.it (Chris Dams) Date: Wed, 13 Dec 2006 13:13:54 +0100 (CET) Subject: [GiNaC-devel] release 1.3.6 In-Reply-To: <20061213080455.GA9517@theor.jinr.ru> Message-ID: Dear Alexei, On Wed, 13 Dec 2006, Sheplyakov Alexei wrote: > ex H1 = color_f(a, c, e)*color_f(b, d, e) > + color_f(a, d, e)*color_f(b, c, e); > > ex test = (H1*H1).expand(expand_options::expand_indexed); > cout << test << endl; > // 2*f.e.b.d*f.e.b.c*f.e.a.c*f.e.a.d+f.symbol8.b.c*f.symbol8.a.d*f.e.b.c*f.e.a.d+f.symbol7.b.d*f.symbol7.a.c*f.e.b.d*f.e.a.c > // inconsistent indices! > > cout << test.simplify_indexed() << endl; > // prints 288, should be 216 At my place this prints 144-2*f.c.a.symbol8*f.a.d.e*f.d.symbol8.b*f.c.e.b. Strange??? @dummy index renaming: yes, this has been much improved in HEAD. In principle I think it would be possible to move the class make_flat_inserter into the *.cpp files. But that would be code duplication. Not so nice. Besides that, new functions were added to indexed.cpp and these need to be called from indexed.h. Fixing all this in a binary compatible way would get way too messy IMO. Maybe we should release 1.4 and claim proudly that we now can rename dummy indices. Good thing that we don't keep an accurate NEWS file. That way we can can announce it like it is new. :-o ;-) Best wishes, Chris From vollinga at physik.uni-wuppertal.de Wed Dec 13 13:58:39 2006 From: vollinga at physik.uni-wuppertal.de (Jens Vollinga) Date: Wed, 13 Dec 2006 13:58:39 +0100 Subject: [GiNaC-devel] release 1.3.6 In-Reply-To: References: Message-ID: <457FF8FF.4000108@physik.uni-wuppertal.de> Dear all, I plan to do the following now (unless counseled otherwise ...): - leave the numerical evaluation of tgamma and friends out of 1.3.6. (sorry for edgy Etch). - don't do anything about the dummy index bug and start a discussion about the next major release 1.4. Regards, Jens From vollinga at physik.uni-wuppertal.de Wed Dec 13 19:15:00 2006 From: vollinga at physik.uni-wuppertal.de (Jens Vollinga) Date: Wed, 13 Dec 2006 19:15:00 +0100 Subject: [GiNaC-devel] Release of GiNaC 1.3.6 Message-ID: <45804324.70908@physik.uni-wuppertal.de> Hello everybody, GiNaC 1.3.6 is out and available. The changes are: - Better worst case behavior in heuristic gcd. - Improved collecting for sparse multivariate polynomials. - Improved collect_common_factors. - Fixed bug in numerical evaluation of multiple polylogs. - Fixed numerical integration of complex functions. - Fixed bug in tensor::replace_contr_index(). As always, this release can be downloaded from http://www.ginac.de/Download.html Best wishes, Jens From varg at theor.jinr.ru Wed Dec 13 20:16:14 2006 From: varg at theor.jinr.ru (Sheplyakov Alexei) Date: Wed, 13 Dec 2006 22:16:14 +0300 Subject: [GiNaC-devel] Re: numerical evaluation of tgamma and co [Was: release 1.3.6] In-Reply-To: References: <20061212170140.GA11136@theor.jinr.ru> Message-ID: <20061213191614.GA29620@theor.jinr.ru> 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 > 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 > (or vector >). > > +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: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: Digital signature URL: From Chris.Dams at mi.infn.it Thu Dec 14 17:40:37 2006 From: Chris.Dams at mi.infn.it (Chris Dams) Date: Thu, 14 Dec 2006 17:40:37 +0100 (CET) Subject: [GiNaC-devel] Re: numerical evaluation of tgamma and co [Was: release 1.3.6] In-Reply-To: <20061213191614.GA29620@theor.jinr.ru> Message-ID: 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 > (or vector >). 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