From fab at fedoraproject.org Sun Feb 1 14:14:50 2009 From: fab at fedoraproject.org (Fabian Affolter) Date: Sun, 01 Feb 2009 14:14:50 +0100 Subject: [GiNaC-devel] ginac Message-ID: <4985A04A.6040704@fedoraproject.org> Hi, I'm packaging ginac for the Fedora Package Collection. Now I have the following rpmlint warning on ginac 1.4.4. Can you have a look at it and have it fixed for the next release, please? [fab at laptop24 i386]$ rpmlint -i ginac* ginac.i386: W: shared-lib-calls-exit /usr/lib/libginac-1.4.so.0.0.4 exit at GLIBC_2.0 This library package calls exit() or _exit(), probably in a non-fork() context. Doing so from a library is strongly discouraged - when a library function calls exit(), it prevents the calling program from handling the error, reporting it to the user, closing files properly, and cleaning up any state that the program has. It is preferred for the library to return an actual error code and let the calling program decide how to handle the situation. Perhaps the intention was to *return* something, and perhaps non-zero? Thanks in advance and kind regards, Fabian -- Fingerprint: 2F6C 930F D3C4 7E38 6AFA 4EB4 E23C D2DD 36A4 397F Fedora always leads and never follows. From fab at fedoraproject.org Sun Feb 1 14:18:27 2009 From: fab at fedoraproject.org (Fabian Affolter) Date: Sun, 01 Feb 2009 14:18:27 +0100 Subject: [GiNaC-devel] Shared lib calls exit Message-ID: <4985A123.50805@fedoraproject.org> Hi, I'm packaging ginac for the Fedora Package Collection. Now I have the following rpmlint warning on ginac 1.4.4. Can you have a look at it and have it fixed for the next release, please? [fab at laptop24 i386]$ rpmlint -i ginac* ginac.i386: W: shared-lib-calls-exit /usr/lib/libginac-1.4.so.0.0.4 exit at GLIBC_2.0 This library package calls exit() or _exit(), probably in a non-fork() context. Doing so from a library is strongly discouraged - when a library function calls exit(), it prevents the calling program from handling the error, reporting it to the user, closing files properly, and cleaning up any state that the program has. It is preferred for the library to return an actual error code and let the calling program decide how to handle the situation. Perhaps the intention was to *return* something, and perhaps non-zero? Thanks in advance and kind regards, Fabian -- Fingerprint: 2F6C 930F D3C4 7E38 6AFA 4EB4 E23C D2DD 36A4 397F Fedora always leads and never follows. From kreckel at ginac.de Sun Feb 1 18:28:21 2009 From: kreckel at ginac.de (Richard B. Kreckel) Date: Sun, 01 Feb 2009 18:28:21 +0100 Subject: [GiNaC-devel] Shared lib calls exit In-Reply-To: <4985A123.50805@fedoraproject.org> References: <4985A123.50805@fedoraproject.org> Message-ID: <4985DBB5.5090909@ginac.de> Fabian Affolter wrote: > I'm packaging ginac for the Fedora Package Collection. Now I have > the following rpmlint warning on ginac 1.4.4. Can you have a look > at it and have it fixed for the next release, please? > > [fab at laptop24 i386]$ rpmlint -i ginac* > ginac.i386: W: shared-lib-calls-exit /usr/lib/libginac-1.4.so.0.0.4 > exit at GLIBC_2.0 > This library package calls exit() or _exit(), probably in a non-fork() > context. Doing so from a library is strongly discouraged - when a > library function calls exit(), it prevents the calling program from > handling the error, reporting it to the user, closing files properly, > and cleaning up any state that the program has. It is preferred for the > library to return an actual error code and let the calling program > decide how to handle the situation. > > Perhaps the intention was to *return* something, and perhaps non-zero? GiNaC itself doesn't call exit() or _exit(). What you're seeing is an artifact introduced into the library by flex. I suggest to ignore this warning for the time being. GiNaC-1.5 won't make use of flex any more in the library proper. Best -richy. -- Richard B. Kreckel From git at ginac.de Tue Feb 3 14:17:56 2009 From: git at ginac.de (Jens Vollinga) Date: Tue, 3 Feb 2009 14:17:56 +0100 (CET) Subject: [GiNaC-devel] [SCM] GiNaC -- a C++ library for symbolic computations branch, master, updated. release_1-4-0-174-gb9dc3d7 Message-ID: <20090203131757.A29F25B4054@cebix.net> This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "GiNaC -- a C++ library for symbolic computations". The branch, master has been updated via b9dc3d71083fe1a2f90a34db24b57b06ad51ebde (commit) via 45b1e47372090352ac5af655b32473df2abab23b (commit) via 3f0b0165865bbb297901e9542fced88a0e32298e (commit) via e79c1f6f914b7be886a19c8d7cdd3603405cda2a (commit) from 38f3143eee71d942f40ab47f5a561dc9736203fc (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- commit b9dc3d71083fe1a2f90a34db24b57b06ad51ebde Author: Jens Vollinga Date: Tue Feb 3 13:50:33 2009 +0100 Fixed compile errors introduced in previous commit 45b1e47372090352ac5af655b32473df2abab23b. commit 45b1e47372090352ac5af655b32473df2abab23b Author: Alexei Sheplyakov Date: Mon Jan 19 08:45:38 2009 +0200 Implement modular multivariate GCD (based on chinese remaindering algorithm). Both algorithm and implementation are a bit inefficient: * algorithm does not make use of sparseness of inputs (and most of multivariate polynomials are quite sparse) * GiNaC's expressions are essentially immutable. Thus some simple operations (i.e. multiplying a polynomial by an element of the base ring) are prohibitively expensive. * All numbers (i.e. GiNaC::numeric objects) are heap allocated. Still it's much faster (~5x on bivariate polynomials, ~100x on 3-variate ones) than (subresultant) PRS algorithm, so gcd() uses modular algorithm by default. commit 3f0b0165865bbb297901e9542fced88a0e32298e Author: Alexei Sheplyakov Date: Mon Jan 19 08:44:36 2009 +0200 Improve (fix?) smod: now it really converts into symmetric representation... ... instead of clumsy convention inspirited by some proprietary CAS. commit e79c1f6f914b7be886a19c8d7cdd3603405cda2a Author: Alexei Sheplyakov Date: Mon Jan 19 08:43:50 2009 +0200 Fix copy-paste error in GINACLIB_MICRO_VERSION. ----------------------------------------------------------------------- Summary of changes: configure.ac | 2 +- doc/tutorial/ginac.texi | 2 +- ginac/Makefile.am | 18 +++ ginac/normal.cpp | 10 ++- ginac/normal.h | 17 +++- ginac/numeric.cpp | 19 ++-- ginac/polynomial/chinrem_gcd.cpp | 14 +++ ginac/polynomial/chinrem_gcd.h | 19 ++++ ginac/polynomial/collect_vargs.cpp | 167 ++++++++++++++++++++++++++++++ ginac/polynomial/collect_vargs.h | 34 ++++++ ginac/polynomial/debug.hpp | 1 + ginac/polynomial/divide_in_z_p.cpp | 90 ++++++++++++++++ ginac/polynomial/divide_in_z_p.h | 27 +++++ ginac/polynomial/euclid_gcd_wrap.h | 60 +++++++++++ ginac/polynomial/eval_point_finder.h | 51 +++++++++ ginac/polynomial/mgcd.cpp | 97 +++++++++++++++++ ginac/polynomial/newton_interpolate.h | 36 +++++++ ginac/polynomial/optimal_vars_finder.cpp | 134 ++++++++++++++++++++++++ ginac/polynomial/optimal_vars_finder.h | 20 ++++ ginac/polynomial/pgcd.cpp | 136 ++++++++++++++++++++++++ ginac/polynomial/pgcd.h | 27 +++++ ginac/polynomial/poly_cra.h | 38 +++++++ ginac/polynomial/primes_factory.h | 60 +++++++++++ ginac/polynomial/primpart_content.cpp | 78 ++++++++++++++ ginac/polynomial/smod_helpers.h | 72 +++++++++++++ 25 files changed, 1215 insertions(+), 14 deletions(-) create mode 100644 ginac/polynomial/chinrem_gcd.cpp create mode 100644 ginac/polynomial/chinrem_gcd.h create mode 100644 ginac/polynomial/collect_vargs.cpp create mode 100644 ginac/polynomial/collect_vargs.h create mode 100644 ginac/polynomial/divide_in_z_p.cpp create mode 100644 ginac/polynomial/divide_in_z_p.h create mode 100644 ginac/polynomial/euclid_gcd_wrap.h create mode 100644 ginac/polynomial/eval_point_finder.h create mode 100644 ginac/polynomial/mgcd.cpp create mode 100644 ginac/polynomial/newton_interpolate.h create mode 100644 ginac/polynomial/optimal_vars_finder.cpp create mode 100644 ginac/polynomial/optimal_vars_finder.h create mode 100644 ginac/polynomial/pgcd.cpp create mode 100644 ginac/polynomial/pgcd.h create mode 100644 ginac/polynomial/poly_cra.h create mode 100644 ginac/polynomial/primes_factory.h create mode 100644 ginac/polynomial/primpart_content.cpp create mode 100644 ginac/polynomial/smod_helpers.h hooks/post-receive -- GiNaC -- a C++ library for symbolic computations From jensv at nikhef.nl Tue Feb 3 14:27:36 2009 From: jensv at nikhef.nl (Jens Vollinga) Date: Tue, 03 Feb 2009 14:27:36 +0100 Subject: [GiNaC-devel] some questions Message-ID: <49884648.8070301@nikhef.nl> Hi, commit 45b1e47372090352ac5af655b32473df2abab23b had some compiling issues and I fixed it. Still, make check does not complete. The timings timing univariate GCD GCD of relatively prime polynomials a and b degree(a) = 100, degree(b) = 50 mod_gcd : 1 1.36e-02 heur_gcd : 1 1.82e-03 sr_gcd: : 1 1.43e+00 Non-trivial GCD, degree(a) = 100, degree(b) = 100 mod_gcd : 51 1.36e-02 heur_gcd : 51 3.64e-03 heur_gcd (old) : 51 5.73e-02 sr_gcd: : 51 2.31e-01 seem to stop at that last output ... I didn't put it through a debugger yet, maybe the test is just too expensive? @Alexei: Is it okay if I put the new files under the copyright of the University of Mainz (as all other files are)? And is it okay if I change the suffices .hpp .tcc? With respect to Richy's "solution" in http://www.ginac.de/pipermail/ginac-devel/2009-February/001544.html, should we do a 1.5 release now/soon? Regards, Jens From varg at metalica.kh.ua Wed Feb 4 16:14:44 2009 From: varg at metalica.kh.ua (Alexei Sheplyakov) Date: Wed, 4 Feb 2009 17:14:44 +0200 Subject: [GiNaC-devel] Release early, release often (Was: some questions) In-Reply-To: <49884648.8070301@nikhef.nl> References: <49884648.8070301@nikhef.nl> Message-ID: <20090204151444.GA28524@metalica.kh.ua> Dear Jens, On Tue, Feb 03, 2009 at 02:27:36PM +0100, Jens Vollinga wrote: > commit 45b1e47372090352ac5af655b32473df2abab23b had some compiling > issues and I fixed it. Thanks a lot. > Still, make check does not complete. The timings > > timing univariate GCD > GCD of relatively prime polynomials a and b > degree(a) = 100, degree(b) = 50 > mod_gcd : 1 1.36e-02 > heur_gcd : 1 1.82e-03 > sr_gcd: : 1 1.43e+00 > Non-trivial GCD, degree(a) = 100, degree(b) = 100 > mod_gcd : 51 1.36e-02 > heur_gcd : 51 3.64e-03 > heur_gcd (old) : 51 5.73e-02 > sr_gcd: : 51 2.31e-01 > > seem to stop at that last output ... I didn't put it through a debugger > yet, maybe the test is just too expensive? Indeed, that test is a bit expensive, but several minutes should be enough. > @Alexei: Is it okay if I put the new files under the copyright of the > University of Mainz (as all other files are)? Yes (as long as license is GPL version >= 2, I don't really care). > And is it okay if I change the suffices .hpp .tcc? OK with me. > With respect to Richy's "solution" in > http://www.ginac.de/pipermail/ginac-devel/2009-February/001544.html, > should we do a 1.5 release now/soon? The subject says it all :) Best regards, Alexei -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 835 bytes Desc: Digital signature URL: From jensv at nikhef.nl Wed Feb 4 16:24:47 2009 From: jensv at nikhef.nl (Jens Vollinga) Date: Wed, 04 Feb 2009 16:24:47 +0100 Subject: [GiNaC-devel] Release early, release often (Was: some questions) In-Reply-To: <20090204151444.GA28524@metalica.kh.ua> References: <49884648.8070301@nikhef.nl> <20090204151444.GA28524@metalica.kh.ua> Message-ID: <4989B33F.9090203@nikhef.nl> Hi Alexei, Alexei Sheplyakov schrieb: >> seem to stop at that last output ... I didn't put it through a debugger >> yet, maybe the test is just too expensive? > > Indeed, that test is a bit expensive, but several minutes should be enough. uhh, it did _not_ finish on my machine Pentium 4 3.2 GHz after more than an hour ... that is strange. I finally killed the process. When I examined a different run with a debugger it didn't look like it was caught in an infinite loop, though, but that was no systematic analysis. >> @Alexei: Is it okay if I put the new files under the copyright of the >> University of Mainz (as all other files are)? > > Yes (as long as license is GPL version >= 2, I don't really care). GPL 2 it will be. >> And is it okay if I change the suffices .hpp .tcc? > > OK with me. .thx >> With respect to Richy's "solution" in >> http://www.ginac.de/pipermail/ginac-devel/2009-February/001544.html, >> should we do a 1.5 release now/soon? > > The subject says it all :) Okay, I am heating up the tool chain ... :-) Regards, Jens From varg at metalica.kh.ua Thu Feb 5 07:53:12 2009 From: varg at metalica.kh.ua (Alexei Sheplyakov) Date: Thu, 5 Feb 2009 08:53:12 +0200 Subject: [GiNaC-devel] Univariate GCD benchmark (Was: some questions) In-Reply-To: <49884648.8070301@nikhef.nl> References: <49884648.8070301@nikhef.nl> Message-ID: <20090205065312.GA30447@metalica.kh.ua> Dear Jens, On Tue, Feb 03, 2009 at 02:27:36PM +0100, Jens Vollinga wrote: > The timings > > timing univariate GCD > GCD of relatively prime polynomials a and b > degree(a) = 100, degree(b) = 50 > mod_gcd : 1 1.36e-02 > heur_gcd : 1 1.82e-03 > sr_gcd: : 1 1.43e+00 > Non-trivial GCD, degree(a) = 100, degree(b) = 100 > mod_gcd : 51 1.36e-02 > heur_gcd : 51 3.64e-03 > heur_gcd (old) : 51 5.73e-02 > sr_gcd: : 51 2.31e-01 > > seem to stop at that last output ... I didn't put it through a debugger > yet, maybe the test is just too expensive? The benchmark works for me just fine, and it doesn't take too much time: timing univarite GCD GCD of relatively prime polynomials a and b degree(a) = 100, degree(b) = 50 mod_gcd : 1 2.18e-03 heur_gcd : 1 3.08e-04 sr_gcd: : 1 2.43e-01 Non-trivial GCD, degree(a) = 100, degree(b) = 100 mod_gcd : 51 5.45e-03 heur_gcd : 51 3.64e-04 heur_gcd (old) : 51 1.75e-02 sr_gcd: : 51 4.65e-02 sr_gcd (old) : 51 1.62e-01 Non-trivial GCD, degree(a) = 1000, degree(b) = 1000 mod_gcd : 501 2.17e+00 heur_gcd : 501 1.24e-02 heur_gcd (old) : 501 2.57e+00 Non-trivial GCD, degree(a) = 2000, degree(b) = 2000 mod_gcd : 1001 1.53e+01 heur_gcd : 1001 4.73e-02 heur_gcd (old) : 1001 1.34e+01 . Actually, it's designed to avoid longish calculations (in order to not annoy users so they don't skip the `make check' step). So I need more info to find out what is going on. Best regards, Alexei -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 835 bytes Desc: Digital signature URL: From kisilv at maths.leeds.ac.uk Thu Feb 5 10:29:45 2009 From: kisilv at maths.leeds.ac.uk (Vladimir V. Kisil) Date: Thu, 5 Feb 2009 09:29:45 +0000 Subject: [GiNaC-devel] Univariate GCD benchmark (Was: some questions) In-Reply-To: <20090205065312.GA30447@metalica.kh.ua> References: <49884648.8070301@nikhef.nl> <20090205065312.GA30447@metalica.kh.ua> Message-ID: Dear Alexei, On Thu, Feb 5, 2009 at 6:53 AM, Alexei Sheplyakov wrote: > mod_gcd : 51 1.36e-02 > > heur_gcd : 51 3.64e-03 > > heur_gcd (old) : 51 5.73e-02 > > sr_gcd: : 51 2.31e-01 > > > > seem to stop at that last output ... I tried it on my PC, the test run endless at this point as well. Best wishes, Vladimir From jensv at nikhef.nl Thu Feb 5 11:40:01 2009 From: jensv at nikhef.nl (Jens Vollinga) Date: Thu, 05 Feb 2009 11:40:01 +0100 Subject: [GiNaC-devel] Univariate GCD benchmark (Was: some questions) In-Reply-To: <20090205065312.GA30447@metalica.kh.ua> References: <49884648.8070301@nikhef.nl> <20090205065312.GA30447@metalica.kh.ua> Message-ID: <498AC201.90009@nikhef.nl> Hi Alexei, Alexei Sheplyakov schrieb: >> seem to stop at that last output ... I didn't put it through a debugger >> yet, maybe the test is just too expensive? > > The benchmark works for me just fine, and it doesn't take too much time: the strange thing is that your original patch did not compile. How can you compile your sources then, anyway? So, maybe your patch was not complete? Another theory would be that I did something wrong applying the patch. I checked that and it seems unlikely. Most of the patch concerned completely new files, which should cause no problems. The rest of the patch seems fine as well. Maybe my "bug fix" that get the includes right introduces this problem? Actually, I cannot image this being the case, but if it is, it would mean that the code has some very serious problems itself (and that should be fixed). > annoy users so they don't skip the `make check' step). So I need more > info to find out what is going on. It is hard to give more information, because the code just keeps on running and the data being processed by several involved functions changes continuously. I'll try to pin it down, but I the best thing to do first, I think, is to find out what the difference between your code and the one in the git repository is! There must be a difference, otherwise your patch would have compiled right away without changes. Regards, Jens From kreckel at ginac.de Thu Feb 5 13:42:59 2009 From: kreckel at ginac.de (Richard B. Kreckel) Date: Thu, 05 Feb 2009 13:42:59 +0100 Subject: [GiNaC-devel] Univariate GCD benchmark (Was: some questions) In-Reply-To: References: <49884648.8070301@nikhef.nl> <20090205065312.GA30447@metalica.kh.ua> Message-ID: <498ADED3.2050708@ginac.de> Vladimir V. Kisil wrote: > On Thu, Feb 5, 2009 at 6:53 AM, Alexei Sheplyakov wrote: > > mod_gcd : 51 1.36e-02 >>> heur_gcd : 51 3.64e-03 >>> heur_gcd (old) : 51 5.73e-02 >>> sr_gcd: : 51 2.31e-01 >>> >>> seem to stop at that last output ... > > I tried it on my PC, the test run endless at this point as well. Strange. I just ran current master HEAD ten times and it finished fine. Also: it is stopping at the old code, right? Cheers -richy. -- Richard B. Kreckel From jensv at nikhef.nl Thu Feb 5 13:43:21 2009 From: jensv at nikhef.nl (Jens Vollinga) Date: Thu, 05 Feb 2009 13:43:21 +0100 Subject: [GiNaC-devel] Univariate GCD benchmark (Was: some questions) In-Reply-To: <20090205065312.GA30447@metalica.kh.ua> References: <49884648.8070301@nikhef.nl> <20090205065312.GA30447@metalica.kh.ua> Message-ID: <498ADEE9.3030808@nikhef.nl> Hi Alexei, chinrem_gcd() cannot deal with the following two polynomials: -936639990-14679334842*x^9-6214147095*x^35+22219362387*x^69-31276301429*x^25+1199649580*x^98+2134905268*x^56+25591410149*x^72+5507703343*x^11+18467021749*x^43+11196778577*x^85+26050790733*x^29-178435747*x^2+1890708440*x^88-561107347*x^13-31038290506*x^51-1330154020*x^15+23467669465*x^59-3966988360*x^16+26794929142*x^38+11598735101*x^75-8608995580*x^3-30174373832*x^46+3580061526*x^91+7814495607*x^20+6624766926*x^78-11990574398*x^54-6863205889*x^33-319408644*x^65-11580405260*x^41-9654281719*x^81+23532819511*x^24-3890383043*x^94+27682281779*x^62+1363904895*x^68-272899085*x^49-933592128*x^97-2954269379*x^28+8432066353*x^36+14038262112*x^71-5474416933*x^84+741141010*x^100+38375274669*x^57-19509035058*x^44-1029159530*x^87+17276957972*x^8+23471621465*x^19-4745283802*x^74-15331409214*x^23-1261023993*x^90+17469329915*x^52-7544450778*x^64+12293848678*x^10-12162845828*x^39+11912265375*x^77-35110566664*x^27-5872201799*x^60+16636451249*x^80-6663332709*x^12+26248623452*x^47+2292551912*x^93 -13410537172*x^14+4255578378*x^55+11614165303*x^31-6270990007*x^34-6744628155*x^67+3692350529*x^96-17204774085*x^63-11157075535*x^18+4275663006*x^70+18517327396*x^42+2030662033*x^83-3435911855*x^50-227816977*x^99+4507833875*x-41046742100*x^37+9385606040*x^73-5892518210*x^22+512268187*x^86+9183261708*x^58-2542140060*x^4-19627087954*x^45+142491112*x^89-4846605217*x^26-4503859503*x^30-38388107386*x^32+2123912816*x^5-2508504600*x^76-15282350857*x^53-12217636980*x^40-4828562936*x^79+1788729074*x^6-967823912*x^92+6436149609*x^7+44704228721*x^61+21474090980*x^17+36034512058*x^66+10918084347*x^21+1913801599*x^82+1530941050*x^48-7104898913*x^95 1882371920+29943249139*x^9-21558061051*x^35+24497174109*x^69+3363043648*x^25+5186524611*x^98-17753230977*x^56+16461882236*x^72+11039962159*x^11-85814533599*x^43-12986831645*x^85+4813620791*x^29-2133682609*x^2+9141433582*x^88-14841292646*x^13+19494168654*x^51-426278523*x^15-18246235652*x^59-12424469513*x^16-14414308862*x^38-16262001424*x^75+1584505491*x^3+6616907060*x^46+9411879011*x^91+7056872613*x^20+29675566382*x^78-48441925739*x^54+12038293769*x^33-22463329638*x^65+21957440404*x^41+26252749471*x^81-28689993421*x^24+1190623161*x^94-3323333429*x^62+778770195*x^68-23673866858*x^49+10263027507*x^97+29115114125*x^28-34230002076*x^36-217623403*x^71-6344703601*x^84+2789684836*x^100-44973929094*x^57-6061422988*x^44+18964048763*x^87+3160532878*x^8-8039690791*x^19-5750277357*x^74+5544486596*x^23+1800283356*x^90-8174921854*x^52+2577247520*x^64-1088265300*x^10+18566882873*x^39+12678193001*x^77-7204610489*x^27+9980611956*x^60+12672890141*x^80+4463462090*x^12-30937311949*x^47-3883570155 *x^93+7561875663*x^14-3850452489*x^55+20714527103*x^31-9973372012*x^34+440594870*x^67+10385086102*x^96-20693764726*x^63+11049483001*x^18-11578701274*x^70-5548876327*x^42+20393397488*x^83+20531692560*x^50+1309311388*x^99-7521320830*x-2750892631*x^37-6001481047*x^73+7149046134*x^22+10287410396*x^86+7332053562*x^58-1135211878*x^4-7420079075*x^45+9742202475*x^89-214559874*x^26+29530802947*x^30-2280622009*x^32-4237029618*x^5+13760397067*x^76+18073788685*x^53+2485463829*x^40+1889202286*x^79+8841198971*x^6+13562767020*x^92+110919258*x^7+6961020716*x^61+11700952246*x^17-13528331424*x^66-19801882818*x^21+25061328813*x^82+1553111326*x^48+4638169279*x^95 Then, chinrem_gcd() calls pgcd() with ever increasing prime numbers ... Either pgcd() returns something bad, or divide_in_z_p() has problems and lets the division check fail. Don't know. Regards, Jens From varg at metalica.kh.ua Thu Feb 5 14:45:15 2009 From: varg at metalica.kh.ua (Alexei Sheplyakov) Date: Thu, 5 Feb 2009 15:45:15 +0200 Subject: [GiNaC-devel] Univariate GCD benchmark (Was: some questions) In-Reply-To: <498AC201.90009@nikhef.nl> References: <49884648.8070301@nikhef.nl> <20090205065312.GA30447@metalica.kh.ua> <498AC201.90009@nikhef.nl> Message-ID: <20090205134515.GA4722@metalica.kh.ua> Hi, On Thu, Feb 05, 2009 at 11:40:01AM +0100, Jens Vollinga wrote: > the strange thing is that your original patch did not compile. How can > you compile your sources then, anyway? I've got CLN and GiNaC headers installed in ~/target/x86_64-linux-gnu/include, so '#include ' happened to work (which is a bad thing). > So, maybe your patch was not complete? It was complete, but a bit incorrect (specifically, I've messed up #include directives). > Another theory would be that I did something wrong applying the patch. I > checked that and it seems unlikely. Most of the patch concerned > completely new files, which should cause no problems. The rest of the > patch seems fine as well. I think the patch was correctly applied. Just in a case, I've built GiNaC from from the `official' branch (before sending the previous mail). Still, `make check' shows no errors (or something unusual) at all. > Maybe my "bug fix" that get the includes right introduces this problem? I doubt it. > Actually, I cannot image this being the case, but if it is, it would > mean that the code has some very serious problems itself (and that > should be fixed). >> annoy users so they don't skip the `make check' step). So I need more >> info to find out what is going on. > > It is hard to give more information, because the code just keeps on > running and the data being processed by several involved functions > changes continuously. The information I'm asking for is: 1. Architecture and OS, 2. Compiler version, 3. CLN version, 4. Compiler flags, 5. Any unusual configuration options. > I'll try to pin it down, but I the best thing to do first, I think, is > to find out what the difference between your code and the one in the git > repository is! $ git branch -a * master origin/GiNaC-international origin/HEAD origin/experimental_fclasses origin/ginac_1-0 origin/ginac_1-1 origin/ginac_1-2 origin/ginac_1-3 origin/ginac_1-4 origin/master $ git remote -v show origin git://www.ginac.de/ginac.git $ git diff origin/master | wc -l 0 That is, there's no difference. Best regards, Alexei -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 835 bytes Desc: Digital signature URL: From jensv at nikhef.nl Thu Feb 5 15:02:21 2009 From: jensv at nikhef.nl (Jens Vollinga) Date: Thu, 05 Feb 2009 15:02:21 +0100 Subject: [GiNaC-devel] Univariate GCD benchmark (Was: some questions) In-Reply-To: <20090205134515.GA4722@metalica.kh.ua> References: <49884648.8070301@nikhef.nl> <20090205065312.GA30447@metalica.kh.ua> <498AC201.90009@nikhef.nl> <20090205134515.GA4722@metalica.kh.ua> Message-ID: <498AF16D.8020700@nikhef.nl> Hi, since it seems to work on the machines of the cln developers, but not on the machines of mere mortals I suspected an important difference between the official cln 1.2.2 and the cln git sources, but the same problem occurs ... still clueless. > The information I'm asking for is: > 1. Architecture and OS, > 2. Compiler version, > 3. CLN version, > 4. Compiler flags, > 5. Any unusual configuration options. Here come the votes of the Dutch jury: 1. x86 and Scientific Linux 3(!!) 2. gcc 4.3.1 20080320 (prerelease) 3. cln 1.2.2 and git repository (as of today) 4. either "-g -Wall" or "-g -O2" for GiNaC, "-g -Wall" for cln 5. No. Built in source dir, build as VPATH build, checked linked libraries, ... automake 1.10.2, autoconf 2.6. Okay, I'll upgrade gcc and will rebuild gmp,cln,GiNaC and see then. Regards, Jens From kisilv at maths.leeds.ac.uk Thu Feb 5 15:19:51 2009 From: kisilv at maths.leeds.ac.uk (Vladimir V. Kisil) Date: Thu, 5 Feb 2009 14:19:51 +0000 Subject: [GiNaC-devel] Univariate GCD benchmark (Was: some questions) In-Reply-To: <498ADED3.2050708@ginac.de> References: <49884648.8070301@nikhef.nl> <20090205065312.GA30447@metalica.kh.ua> <498ADED3.2050708@ginac.de> Message-ID: On Thu, Feb 5, 2009 at 12:42 PM, Richard B. Kreckel wrote: > Strange. I just ran current master HEAD ten times and it finished fine. I tried with HEAD as well with the same result: an endless run. My configuration is: 1. Debian (testing):uname -a Linux desktop 2.6.26-1-686 #1 SMP Sat Jan 10 18:29:31 UTC 2009 i686 GNU/Linux 2. gcc -v Using built-in specs. Target: i486-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.2-1.1' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --enable-targets=all --enable-cld --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu Thread model: posix gcc version 4.3.2 (Debian 4.3.2-1.1) 3. libcln5 1.2.2-2 4. GiNaC is obtained by git-clone git://www.ginac.de/ginac.git head then cd head && autoreconf -i && ./debian/rules binary && make check Best wishes, Vladimir From kreckel at ginac.de Thu Feb 5 21:59:02 2009 From: kreckel at ginac.de (Richard B. Kreckel) Date: Thu, 05 Feb 2009 21:59:02 +0100 Subject: [GiNaC-devel] Univariate GCD benchmark (Was: some questions) In-Reply-To: References: <49884648.8070301@nikhef.nl> <20090205065312.GA30447@metalica.kh.ua> <498ADED3.2050708@ginac.de> Message-ID: <498B5316.9050401@ginac.de> Vladimir V. Kisil wrote: > On Thu, Feb 5, 2009 at 12:42 PM, Richard B. Kreckel wrote: >> Strange. I just ran current master HEAD ten times and it finished fine. > > I tried with HEAD as well with the same result: an endless run. My > configuration is: > > 1. Debian (testing):uname -a > Linux desktop 2.6.26-1-686 #1 SMP Sat Jan 10 18:29:31 UTC 2009 i686 GNU/Linux > 2. gcc -v > Using built-in specs. > Target: i486-linux-gnu > Configured with: ../src/configure -v --with-pkgversion='Debian > 4.3.2-1.1' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs > --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr > --enable-shared --with-system-zlib --libexecdir=/usr/lib > --without-included-gettext --enable-threads=posix --enable-nls > --with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3 > --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc > --enable-mpfr --enable-targets=all --enable-cld > --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu > --target=i486-linux-gnu > Thread model: posix > gcc version 4.3.2 (Debian 4.3.2-1.1) > 3. libcln5 1.2.2-2 > 4. GiNaC is obtained by > git-clone git://www.ginac.de/ginac.git head > then > cd head && autoreconf -i && ./debian/rules binary && make check I was about to say that my environment is the same. Until I realized: I'm using a 64 bit system! This suggest the theory that it works in 64 bit systems and doesn't work on 32 bit systems, right? -richy. -- Richard B. Kreckel From varg at metalica.kh.ua Fri Feb 6 07:57:32 2009 From: varg at metalica.kh.ua (Alexei Sheplyakov) Date: Fri, 6 Feb 2009 08:57:32 +0200 Subject: [GiNaC-devel] chinrem_gcd() bugfix (Was: Univariate GCD benchmark) In-Reply-To: References: <49884648.8070301@nikhef.nl> <20090205065312.GA30447@metalica.kh.ua> <498ADED3.2050708@ginac.de> Message-ID: <20090206065732.GA10220@metalica.kh.ua> Hello, On Thu, Feb 05, 2009 at 02:19:51PM +0000, Vladimir V. Kisil wrote: > I tried with HEAD as well with the same result: an endless run. My > configuration is: > > 1. Debian (testing):uname -a > Linux desktop 2.6.26-1-686 #1 SMP Sat Jan 10 18:29:31 UTC 2009 i686 GNU/Linux > 2. gcc -v > Using built-in specs. > Target: i486-linux-gnu > Configured with: ../src/configure -v --with-pkgversion='Debian > 4.3.2-1.1' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs > --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr > --enable-shared --with-system-zlib --libexecdir=/usr/lib > --without-included-gettext --enable-threads=posix --enable-nls > --with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3 > --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc > --enable-mpfr --enable-targets=all --enable-cld > --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu > --target=i486-linux-gnu > Thread model: posix > gcc version 4.3.2 (Debian 4.3.2-1.1) > 3. libcln5 1.2.2-2 > 4. GiNaC is obtained by > git-clone git://www.ginac.de/ginac.git head > then > cd head && autoreconf -i && ./debian/rules binary && make check Could you please try the patch below? From: Alexei Sheplyakov Subject: [PATCH] [BUGFIX] Fix chinese_remainder() so modular GCD actually works. --- check/Makefile.am | 4 ++++ check/bugme_chinrem_gcd.cpp | 32 ++++++++++++++++++++++++++++++++ ginac/polynomial/poly_cra.h | 2 +- 3 files changed, 37 insertions(+), 1 deletions(-) create mode 100644 check/bugme_chinrem_gcd.cpp diff --git a/check/Makefile.am b/check/Makefile.am index b601756..62470f2 100644 --- a/check/Makefile.am +++ b/check/Makefile.am @@ -29,6 +29,7 @@ EXAMS = exam_paranoia \ exam_hashmap \ exam_misc \ exam_mod_gcd \ + bugme_chinrem_gcd \ exam_cra TIMES = time_dennyfliegner \ @@ -251,6 +252,9 @@ time_parser_SOURCES = time_parser.cpp \ randomize_serials.cpp timer.cpp timer.h time_parser_LDADD = ../ginac/libginac.la +bugme_chinrem_gcd_SOURCES = bugme_chinrem_gcd.cpp +bugme_chinrem_gcd_LDADD = ../ginac/libginac.la + AM_CPPFLAGS = -I$(srcdir)/../ginac -I../ginac -DIN_GINAC diff --git a/check/bugme_chinrem_gcd.cpp b/check/bugme_chinrem_gcd.cpp new file mode 100644 index 0000000..0b422c2 --- /dev/null +++ b/check/bugme_chinrem_gcd.cpp @@ -0,0 +1,32 @@ +/** + * @file bugme_chinrem_gcd.cpp + * A small program exposing historical bug in poly_cra function. + */ +#include +#include +#include "ginac.h" +using namespace std; +namespace GiNaC +{ +extern ex chinrem_gcd(const ex& A, const ex& B); +} +using namespace GiNaC; + +static const std::string p1_srep("\ +-936639990-14679334842*x^9-6214147095*x^35+22219362387*x^69-31276301429*x^25+1199649580*x^98+2134905268*x^56+25591410149*x^72+5507703343*x^11+18467021749*x^43+11196778577*x^85+26050790733*x^29-178435747*x^2+1890708440*x^88-561107347*x^13-31038290506*x^51-1330154020*x^15+23467669465*x^59-3966988360*x^16+26794929142*x^38+11598735101*x^75-8608995580*x^3-30174373832*x^46+3580061526*x^91+7814495607*x^20+6624766926*x^78-11990574398*x^54-6863205889*x^33-319408644*x^65-11580405260*x^41-9654281719*x^81+23532819511*x^24-3890383043*x^94+27682281779*x^62+1363904895*x^68-272899085*x^49-933592128*x^97-2954269379*x^28+8432066353*x^36+14038262112*x^71-5474416933*x^84+741141010*x^100+38375274669*x^57-19509035058*x^44-1029159530*x^87+17276957972*x^8+23471621465*x^19-4745283802*x^74-15331409214*x^23-1261023993*x^90+17469329915*x^52-7544450778*x^64+12293848678*x^10-12162845828*x^39+11912265375*x^77-35110566664*x^27-5872201799*x^60+16636451249*x^80-6663332709*x^12+26248623452*x^47+2292551912*x^93-13410537172*x^14+4255578378*x^55+11614165303*x^31-6270990007*x^34-6744628155*x^67+3692350529*x^96-17204774085*x^63-11157075535*x^18+4275663006*x^70+18517327396*x^42+2030662033*x^83-3435911855*x^50-227816977*x^99+4507833875*x-41046742100*x^37+9385606040*x^73-5892518210*x^22+512268187*x^86+9183261708*x^58-2542140060*x^4-19627087954*x^45+142491112*x^89-4846605217*x^26-4503859503*x^30-38388107386*x^32+2123912816*x^5-2508504600*x^76-15282350857*x^53-12217636980*x^40-4828562936*x^79+1788729074*x^6-967823912*x^92+6436149609*x^7+44704228721*x^61+21474090980*x^17+36034512058*x^66+10918084347*x^21+1913801599*x^82+1530941050*x^48-7104898913*x^95"); + + +static const std::string p2_srep("\ +1882371920+29943249139*x^9-21558061051*x^35+24497174109*x^69+3363043648*x^25+5186524611*x^98-17753230977*x^56+16461882236*x^72+11039962159*x^11-85814533599*x^43-12986831645*x^85+4813620791*x^29-2133682609*x^2+9141433582*x^88-14841292646*x^13+19494168654*x^51-426278523*x^15-18246235652*x^59-12424469513*x^16-14414308862*x^38-16262001424*x^75+1584505491*x^3+6616907060*x^46+9411879011*x^91+7056872613*x^20+29675566382*x^78-48441925739*x^54+12038293769*x^33-22463329638*x^65+21957440404*x^41+26252749471*x^81-28689993421*x^24+1190623161*x^94-3323333429*x^62+778770195*x^68-23673866858*x^49+10263027507*x^97+29115114125*x^28-34230002076*x^36-217623403*x^71-6344703601*x^84+2789684836*x^100-44973929094*x^57-6061422988*x^44+18964048763*x^87+3160532878*x^8-8039690791*x^19-5750277357*x^74+5544486596*x^23+1800283356*x^90-8174921854*x^52+2577247520*x^64-1088265300*x^10+18566882873*x^39+12678193001*x^77-7204610489*x^27+9980611956*x^60+12672890141*x^80+4463462090*x^12-30937311949*x^47-3883570155*x^93+7561875663*x^14-3850452489*x^55+20714527103*x^31-9973372012*x^34+440594870*x^67+10385086102*x^96-20693764726*x^63+11049483001*x^18-11578701274*x^70-5548876327*x^42+20393397488*x^83+20531692560*x^50+1309311388*x^99-7521320830*x-2750892631*x^37-6001481047*x^73+7149046134*x^22+10287410396*x^86+7332053562*x^58-1135211878*x^4-7420079075*x^45+9742202475*x^89-214559874*x^26+29530802947*x^30-2280622009*x^32-4237029618*x^5+13760397067*x^76+18073788685*x^53+2485463829*x^40+1889202286*x^79+8841198971*x^6+13562767020*x^92+110919258*x^7+6961020716*x^61+11700952246*x^17-13528331424*x^66-19801882818*x^21+25061328813*x^82+1553111326*x^48+4638169279*x^95"); + +int main(int argc, char** argv) +{ + cout << "checking for bugs in poly_cra() " << flush; + parser the_parser; + ex p1 = the_parser(p1_srep); + ex p2 = the_parser(p2_srep); + ex g = chinrem_gcd(p1, p2); + cout << "not found."; + return 0; +} + diff --git a/ginac/polynomial/poly_cra.h b/ginac/polynomial/poly_cra.h index cbcff7b..2f68034 100644 --- a/ginac/polynomial/poly_cra.h +++ b/ginac/polynomial/poly_cra.h @@ -28,7 +28,7 @@ ex chinese_remainder(const ex& e1, const cln::cl_I& q1, ex v2 = (e2.smod(q2n) - v1.smod(q2n)).expand().smod(q2n); const numeric q1_1(recip(q1, q2)); // 1/q_1 mod q_2 v2 = (v2*q1_1).smod(q2n); - ex ret = (v1 + v2*q1_1).expand(); + ex ret = (v1 + v2*q1n).expand(); return ret; } -- 1.5.6.5 Best regards, Alexei -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 835 bytes Desc: Digital signature URL: From varg at metalica.kh.ua Fri Feb 6 08:12:22 2009 From: varg at metalica.kh.ua (Alexei Sheplyakov) Date: Fri, 6 Feb 2009 09:12:22 +0200 Subject: [GiNaC-devel] Univariate GCD benchmark (Was: some questions) In-Reply-To: <498B5316.9050401@ginac.de> References: <49884648.8070301@nikhef.nl> <20090205065312.GA30447@metalica.kh.ua> <498ADED3.2050708@ginac.de> <498B5316.9050401@ginac.de> Message-ID: <20090206071222.GB10220@metalica.kh.ua> Hi, On Thu, Feb 05, 2009 at 09:59:02PM +0100, Richard B. Kreckel wrote: > I was about to say that my environment is the same. Until I realized: > I'm using a 64 bit system! /me too. > This suggest the theory that it works in 64 bit systems and doesn't work > on 32 bit systems, right? I've got another theory. There was a bug in chinese_remainder() function. It's easy to spot it on 32-bit architecture, but not on 64-bit one. If my theory is correct, the patch below should trigger the bug on 64-bit architecture. Could you please try it (WITHOUT applying a patch which is supposed to fix the bug, of course)? Note: this patch is not supposed to be applied to the `official' repository. diff --git a/ginac/polynomial/primes_factory.h b/ginac/polynomial/primes_factory.h index 093c973..d80bff7 100644 --- a/ginac/polynomial/primes_factory.h +++ b/ginac/polynomial/primes_factory.h @@ -25,7 +25,7 @@ private: cln::cl_I last; // This ensures coefficients are immediate. static const int immediate_bits = 8*sizeof(void *) - __alignof__(void *); - static const long opt_hint = (1L << (immediate_bits >> 1)) - 1; + static const long opt_hint = (1L << 14) - 1L; public: primes_factory() { Best regards, Alexei -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 835 bytes Desc: Digital signature URL: From varg at metalica.kh.ua Fri Feb 6 09:18:00 2009 From: varg at metalica.kh.ua (Alexei Sheplyakov) Date: Fri, 6 Feb 2009 10:18:00 +0200 Subject: [GiNaC-devel] Univariate GCD benchmark (Was: some questions) In-Reply-To: <498ADED3.2050708@ginac.de> References: <49884648.8070301@nikhef.nl> <20090205065312.GA30447@metalica.kh.ua> <498ADED3.2050708@ginac.de> Message-ID: <20090206081800.GA12584@metalica.kh.ua> Hi, On Thu, Feb 05, 2009 at 01:42:59PM +0100, Richard B. Kreckel wrote: > Strange. I just ran current master HEAD ten times and it finished fine. > > Also: it is stopping at the old code, right? Short answer: no (it's a bug on its own). Long(er) answer: The benchmark is intended to a) check for bugs in mod_gcd (modular GCD algorithm for univariate polynomials using vector of coefficients to store polynomials), b) find out how (in)efficient GiNaC::ex is as a representation of univariate polynomials. To do this it calls different implementations of the same GCD calculation method. So, it's not supposed to call chinrem_gcd() in first place, but for some reason it does. It's a bug in the test itself. Fortunately this bug uncovered much more severe bug (in multivariate GCD code). I'll fix the test after I find out what is wrong with chinrem_gcd(). Best regards, Alexei -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 835 bytes Desc: Digital signature URL: From jensv at nikhef.nl Fri Feb 6 10:54:44 2009 From: jensv at nikhef.nl (Jens Vollinga) Date: Fri, 06 Feb 2009 10:54:44 +0100 Subject: [GiNaC-devel] chinrem_gcd() bugfix (Was: Univariate GCD benchmark) In-Reply-To: <20090206065732.GA10220@metalica.kh.ua> References: <49884648.8070301@nikhef.nl> <20090205065312.GA30447@metalica.kh.ua> <498ADED3.2050708@ginac.de> <20090206065732.GA10220@metalica.kh.ua> Message-ID: <498C08E4.3090103@nikhef.nl> Hi, Alexei Sheplyakov schrieb: > Could you please try the patch below? > > From: Alexei Sheplyakov > Subject: [PATCH] [BUGFIX] Fix chinese_remainder() so modular GCD actually works. that works! I'll put it into the repository then. Regards, Jens From git at ginac.de Fri Feb 6 13:17:27 2009 From: git at ginac.de (Jens Vollinga) Date: Fri, 6 Feb 2009 13:17:27 +0100 (CET) Subject: [GiNaC-devel] [SCM] GiNaC -- a C++ library for symbolic computations branch, master, updated. release_1-4-0-177-g3627c2c Message-ID: <20090206121728.234B65B40F3@cebix.net> This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "GiNaC -- a C++ library for symbolic computations". The branch, master has been updated via 3627c2c0f2fe8fe04816703c5fc6dad9c96fb0a6 (commit) via a3a0f8b23bb70802cb0fc952cafdc2223c892fe9 (commit) via 80b1c3e0ee0e465d56e5c76bef4e52ef2dbc5197 (commit) from b9dc3d71083fe1a2f90a34db24b57b06ad51ebde (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- commit 3627c2c0f2fe8fe04816703c5fc6dad9c96fb0a6 Author: Alexei Sheplyakov Date: Fri Feb 6 08:57:32 2009 +0200 Fix chinese_remainder() so modular GCD actually works. commit a3a0f8b23bb70802cb0fc952cafdc2223c892fe9 Author: Jens Vollinga Date: Fri Feb 6 13:13:06 2009 +0100 Automake now needs to be version >=1.8. Older versions like 1.7.9 do not create the directory m4 in a VPATH build. commit 80b1c3e0ee0e465d56e5c76bef4e52ef2dbc5197 Author: Jens Vollinga Date: Thu Feb 5 10:54:21 2009 +0100 Renamed files *.tcc and *.hpp to *.h. ----------------------------------------------------------------------- Summary of changes: check/Makefile.am | 6 +++- check/bugme_chinrem_gcd.cpp | 32 ++++++++++++++++++++ check/{error_report.hpp => error_report.h} | 0 check/exam_cra.cpp | 2 +- check/exam_mod_gcd.cpp | 6 ++-- check/match_bug.cpp | 2 +- check/time_uvar_gcd.cpp | 8 ++-- configure.ac | 2 +- ginac/Makefile.am | 26 ++++++++-------- ginac/ginac.h | 4 +- ginac/parser/{debug.hpp => debug.h} | 0 ginac/parser/default_reader.tpl | 2 +- ginac/parser/lexer.cpp | 2 +- ginac/parser/{lexer.hpp => lexer.h} | 0 ginac/parser/parse_binop_rhs.cpp | 6 ++-- ginac/parser/parse_context.cpp | 2 +- .../parser/{parse_context.hpp => parse_context.h} | 0 ginac/parser/parser.cpp | 6 ++-- ginac/parser/{parser.hpp => parser.h} | 2 +- ginac/parser/parser_compat.cpp | 2 +- ginac/polynomial/collect_vargs.cpp | 2 +- ginac/polynomial/cra_garner.cpp | 2 +- ginac/polynomial/{cra_garner.hpp => cra_garner.h} | 0 ginac/polynomial/{debug.hpp => debug.h} | 0 ginac/polynomial/euclid_gcd_wrap.h | 6 ++-- ginac/polynomial/eval_uvar.h | 4 +- ginac/polynomial/{gcd_euclid.tcc => gcd_euclid.h} | 10 +++--- ginac/polynomial/gcd_uvar.cpp | 2 +- ginac/polynomial/heur_gcd_uvar.h | 8 ++-- ginac/polynomial/interpolate_padic_uvar.h | 2 +- ginac/polynomial/mod_gcd.cpp | 8 ++-- ginac/polynomial/{mod_gcd.hpp => mod_gcd.h} | 2 +- ginac/polynomial/{normalize.tcc => normalize.h} | 6 ++-- ginac/polynomial/poly_cra.h | 2 +- ginac/polynomial/prem_uvar.h | 6 ++-- ginac/polynomial/primes_factory.h | 2 +- ginac/polynomial/primpart_content.cpp | 2 +- ginac/polynomial/{remainder.tcc => remainder.h} | 8 ++-- .../polynomial/{ring_traits.hpp => ring_traits.h} | 0 ginac/polynomial/smod_helpers.h | 2 +- ginac/polynomial/sr_gcd_uvar.h | 6 ++-- ginac/polynomial/{upoly.hpp => upoly.h} | 4 +- ginac/polynomial/upoly_io.cpp | 4 +- ginac/polynomial/{upoly_io.hpp => upoly_io.h} | 2 +- 44 files changed, 118 insertions(+), 82 deletions(-) create mode 100644 check/bugme_chinrem_gcd.cpp rename check/{error_report.hpp => error_report.h} (100%) rename ginac/parser/{debug.hpp => debug.h} (100%) rename ginac/parser/{lexer.hpp => lexer.h} (100%) rename ginac/parser/{parse_context.hpp => parse_context.h} (100%) rename ginac/parser/{parser.hpp => parser.h} (98%) rename ginac/polynomial/{cra_garner.hpp => cra_garner.h} (100%) rename ginac/polynomial/{debug.hpp => debug.h} (100%) rename ginac/polynomial/{gcd_euclid.tcc => gcd_euclid.h} (84%) rename ginac/polynomial/{mod_gcd.hpp => mod_gcd.h} (88%) rename ginac/polynomial/{normalize.tcc => normalize.h} (96%) rename ginac/polynomial/{remainder.tcc => remainder.h} (96%) rename ginac/polynomial/{ring_traits.hpp => ring_traits.h} (100%) rename ginac/polynomial/{upoly.hpp => upoly.h} (98%) rename ginac/polynomial/{upoly_io.hpp => upoly_io.h} (92%) hooks/post-receive -- GiNaC -- a C++ library for symbolic computations From git at ginac.de Fri Feb 6 16:51:45 2009 From: git at ginac.de (Jens Vollinga) Date: Fri, 6 Feb 2009 16:51:45 +0100 (CET) Subject: [GiNaC-devel] [SCM] GiNaC -- a C++ library for symbolic computations branch, master, updated. release_1-4-0-182-gfc16eff Message-ID: <20090206155145.679715B40F0@cebix.net> This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "GiNaC -- a C++ library for symbolic computations". The branch, master has been updated via fc16effeefb35845d77d98b2173160131bafa9b3 (commit) via 0d22af8982798509662a897ce72f546fe2149d0c (commit) via 2251ede3f4b3e7066f83fbedba53181c03f633f7 (commit) via bf08e105894751acc66f337074be6a5b9e738220 (commit) via 1602530f716ba1d425a0667b897182b99c374823 (commit) from 3627c2c0f2fe8fe04816703c5fc6dad9c96fb0a6 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- commit fc16effeefb35845d77d98b2173160131bafa9b3 Author: Jens Vollinga Date: Fri Feb 6 16:49:47 2009 +0100 Adjusted NEWS and INSTALL documentation. commit 0d22af8982798509662a897ce72f546fe2149d0c Author: Jens Vollinga Date: Fri Feb 6 16:35:22 2009 +0100 Missed to change one date in function.pl. commit 2251ede3f4b3e7066f83fbedba53181c03f633f7 Author: Jens Vollinga Date: Fri Feb 6 16:24:58 2009 +0100 Changed name of debugging macro (to avoid warning cause by multiple definition). commit bf08e105894751acc66f337074be6a5b9e738220 Author: Jens Vollinga Date: Fri Feb 6 16:22:58 2009 +0100 Fixed returning of test result (++result was +result). commit 1602530f716ba1d425a0667b897182b99c374823 Author: Jens Vollinga Date: Fri Feb 6 16:07:10 2009 +0100 Prettified source code. - Added copyright and GPL licencing to new files. - Increased year to 2009. - Changed guarding macros in header to uniform pattern without leading or trailing __ (double underscores). - Put includes of system wide header consistently below own includes (help a tiny bit to clarify dependencies). ----------------------------------------------------------------------- Summary of changes: INSTALL | 2 +- NEWS | 3 +- check/bugme_chinrem_gcd.cpp | 36 ++++++++++++++----- check/check_inifcns.cpp | 9 +++-- check/check_lsolve.cpp | 9 +++-- check/check_matrices.cpp | 9 +++-- check/check_numeric.cpp | 9 +++-- check/error_report.h | 33 ++++++++++++++--- check/exam_archive.cpp | 9 +++-- check/exam_clifford.cpp | 7 ++-- check/exam_color.cpp | 7 ++-- check/exam_cra.cpp | 34 ++++++++++++++--- check/exam_differentiation.cpp | 7 ++-- check/exam_factor.cpp | 7 ++-- check/exam_hashmap.cpp | 9 +++-- check/exam_indexed.cpp | 7 ++-- check/exam_inifcns.cpp | 7 ++-- check/exam_inifcns_nstdsums.cpp | 8 ++-- check/exam_inifcns_nstdsums.h | 22 +++++++++++ check/exam_lsolve.cpp | 7 ++-- check/exam_matrices.cpp | 9 +++-- check/exam_misc.cpp | 7 ++-- check/exam_mod_gcd.cpp | 33 ++++++++++++++--- check/exam_normalization.cpp | 7 ++-- check/exam_numeric.cpp | 8 ++-- check/exam_paranoia.cpp | 7 ++-- check/exam_polygcd.cpp | 7 ++-- check/exam_powerlaws.cpp | 7 ++-- check/exam_pseries.cpp | 7 ++-- check/exam_structure.cpp | 6 ++-- check/genex.cpp | 7 ++-- check/heur_gcd_bug.cpp | 33 +++++++++++++---- check/match_bug.cpp | 33 +++++++++++++---- check/mul_eval_memleak.cpp | 31 ++++++++-------- check/numeric_archive.cpp | 38 +++++++++++++++----- check/parser_bugs.cpp | 31 +++++++++++++--- check/parser_memleak.cpp | 37 +++++++++++++++---- check/randomize_serials.cpp | 30 +++++++++++++-- check/test_runner.h | 33 ++++++++++++++--- check/time_antipode.cpp | 17 +++++---- check/time_dennyfliegner.cpp | 9 +++-- check/time_fateman_expand.cpp | 7 ++-- check/time_gammaseries.cpp | 9 +++-- check/time_hashmap.cpp | 9 +++-- check/time_lw_A.cpp | 9 +++-- check/time_lw_B.cpp | 9 +++-- check/time_lw_C.cpp | 9 +++-- check/time_lw_D.cpp | 9 +++-- check/time_lw_E.cpp | 9 +++-- check/time_lw_F.cpp | 9 +++-- check/time_lw_G.cpp | 9 +++-- check/time_lw_H.cpp | 9 +++-- check/time_lw_IJKL.cpp | 9 +++-- check/time_lw_M1.cpp | 7 ++-- check/time_lw_M2.cpp | 7 ++-- check/time_lw_N.cpp | 9 +++-- check/time_lw_O.cpp | 9 +++-- check/time_lw_P.cpp | 9 +++-- check/time_lw_Pprime.cpp | 9 +++-- check/time_lw_Q.cpp | 9 +++-- check/time_lw_Qprime.cpp | 9 +++-- check/time_parser.cpp | 40 ++++++++++++++++---- check/time_toeplitz.cpp | 9 +++-- check/time_uvar_gcd.cpp | 42 ++++++++++++++++----- check/time_vandermonde.cpp | 9 +++-- check/timer.cpp | 8 ++-- check/timer.h | 3 +- doc/tutorial/ginac.texi | 6 ++-- ginac/add.cpp | 12 +++--- ginac/add.h | 8 ++-- ginac/archive.cpp | 8 ++-- ginac/archive.h | 11 +++--- ginac/assertion.h | 8 ++-- ginac/basic.cpp | 10 +++--- ginac/basic.h | 24 ++++++------ ginac/class_info.h | 16 ++++---- ginac/clifford.cpp | 6 ++-- ginac/clifford.h | 9 ++--- ginac/color.cpp | 8 ++-- ginac/color.h | 10 ++--- ginac/compiler.h | 28 +++++++++++++-- ginac/constant.cpp | 10 +++--- ginac/constant.h | 11 +++--- ginac/container.h | 23 ++++++------ ginac/ex.cpp | 8 ++-- ginac/ex.h | 17 ++++----- ginac/excompiler.cpp | 23 ++++++------ ginac/excompiler.h | 16 ++++----- ginac/expair.cpp | 6 ++-- ginac/expair.h | 8 ++-- ginac/expairseq.cpp | 13 +++---- ginac/expairseq.h | 20 +++++----- ginac/exprseq.cpp | 2 +- ginac/exprseq.h | 12 +++--- ginac/factor.cpp | 2 +- ginac/factor.h | 12 +++---- ginac/fail.cpp | 6 ++-- ginac/fail.h | 8 ++-- ginac/fderivative.cpp | 6 ++-- ginac/fderivative.h | 13 +++---- ginac/flags.h | 8 ++-- ginac/function.pl | 31 ++++++++-------- ginac/ginac.h | 8 ++-- ginac/hash_map.h | 13 +++---- ginac/idx.cpp | 10 +++--- ginac/idx.h | 9 ++--- ginac/indexed.cpp | 12 +++--- ginac/indexed.h | 13 +++---- ginac/inifcns.cpp | 8 ++-- ginac/inifcns.h | 8 ++-- ginac/inifcns_gamma.cpp | 8 ++-- ginac/inifcns_nstdsums.cpp | 11 +++--- ginac/inifcns_trans.cpp | 8 ++-- ginac/integral.cpp | 2 +- ginac/integral.h | 8 ++-- ginac/lst.cpp | 2 +- ginac/lst.h | 12 +++--- ginac/matrix.cpp | 16 ++++---- ginac/matrix.h | 14 ++++---- ginac/mul.cpp | 12 +++--- ginac/mul.h | 8 ++-- ginac/ncmul.cpp | 10 +++--- ginac/ncmul.h | 8 ++-- ginac/normal.cpp | 8 ++-- ginac/normal.h | 8 ++-- ginac/numeric.cpp | 14 ++++---- ginac/numeric.h | 14 +++---- ginac/operators.cpp | 8 ++-- ginac/operators.h | 8 ++-- ginac/parser/debug.h | 34 +++++++++++++++--- ginac/parser/lexer.cpp | 34 ++++++++++++++--- ginac/parser/lexer.h | 34 ++++++++++++++--- ginac/parser/parse_binop_rhs.cpp | 31 +++++++++++++--- ginac/parser/parse_context.cpp | 30 +++++++++++++-- ginac/parser/parse_context.h | 40 ++++++++++++++++----- ginac/parser/parser.cpp | 30 +++++++++++++-- ginac/parser/parser.h | 35 ++++++++++++++---- ginac/parser/parser_compat.cpp | 34 ++++++++++++++---- ginac/polynomial/chinrem_gcd.cpp | 27 ++++++++++++-- ginac/polynomial/chinrem_gcd.h | 31 +++++++++++++--- ginac/polynomial/collect_vargs.cpp | 39 +++++++++++++++----- ginac/polynomial/collect_vargs.h | 35 +++++++++++++++--- ginac/polynomial/cra_garner.cpp | 34 ++++++++++++++--- ginac/polynomial/cra_garner.h | 34 +++++++++++++++--- ginac/polynomial/debug.h | 57 ++++++++++++++++++++--------- ginac/polynomial/divide_in_z_p.cpp | 28 +++++++++++++-- ginac/polynomial/divide_in_z_p.h | 29 +++++++++++++-- ginac/polynomial/euclid_gcd_wrap.h | 28 +++++++++++++-- ginac/polynomial/eval_point_finder.h | 32 ++++++++++++++--- ginac/polynomial/eval_uvar.h | 33 ++++++++++++++--- ginac/polynomial/gcd_euclid.h | 33 ++++++++++++++--- ginac/polynomial/gcd_uvar.cpp | 29 +++++++++++++-- ginac/polynomial/heur_gcd_uvar.h | 34 ++++++++++++++--- ginac/polynomial/interpolate_padic_uvar.h | 37 +++++++++++++++---- ginac/polynomial/mgcd.cpp | 29 +++++++++++++-- ginac/polynomial/mod_gcd.cpp | 32 ++++++++++++++--- ginac/polynomial/mod_gcd.h | 35 +++++++++++++++--- ginac/polynomial/newton_interpolate.h | 32 ++++++++++++++-- ginac/polynomial/normalize.h | 33 ++++++++++++++--- ginac/polynomial/optimal_vars_finder.cpp | 35 ++++++++++++++---- ginac/polynomial/optimal_vars_finder.h | 36 ++++++++++++++++--- ginac/polynomial/pgcd.cpp | 26 ++++++++++++-- ginac/polynomial/pgcd.h | 28 +++++++++++++-- ginac/polynomial/poly_cra.h | 32 ++++++++++++++--- ginac/polynomial/prem_uvar.h | 35 ++++++++++++++---- ginac/polynomial/primes_factory.h | 34 ++++++++++++++--- ginac/polynomial/primpart_content.cpp | 26 ++++++++++++-- ginac/polynomial/remainder.h | 35 +++++++++++++++--- ginac/polynomial/ring_traits.h | 34 ++++++++++++++--- ginac/polynomial/smod_helpers.h | 31 ++++++++++++++-- ginac/polynomial/sr_gcd_uvar.h | 36 +++++++++++++++---- ginac/polynomial/upoly.h | 48 ++++++++++++++++++------- ginac/polynomial/upoly_io.cpp | 50 ++++++++++++++++++------- ginac/polynomial/upoly_io.h | 39 ++++++++++++++++---- ginac/power.cpp | 12 +++--- ginac/power.h | 8 ++-- ginac/print.cpp | 6 ++-- ginac/print.h | 15 ++++---- ginac/pseries.cpp | 10 +++--- ginac/pseries.h | 8 ++-- ginac/ptr.h | 13 +++---- ginac/registrar.cpp | 8 ++-- ginac/registrar.h | 18 +++++----- ginac/relational.cpp | 8 ++-- ginac/relational.h | 8 ++-- ginac/remember.cpp | 6 ++-- ginac/remember.h | 10 +++--- ginac/structure.h | 14 +++---- ginac/symbol.cpp | 10 +++--- ginac/symbol.h | 13 ++++--- ginac/symmetry.cpp | 12 +++--- ginac/symmetry.h | 13 +++---- ginac/tensor.cpp | 10 +++--- ginac/tensor.h | 9 ++--- ginac/tostring.h | 8 ++-- ginac/utils.cpp | 2 +- ginac/utils.h | 14 +++---- ginac/wildcard.cpp | 6 ++-- ginac/wildcard.h | 9 ++--- ginsh/ginsh.1.in | 2 +- ginsh/ginsh.h | 2 +- ginsh/ginsh_extensions.h | 2 +- ginsh/ginsh_lexer.ll | 2 +- ginsh/ginsh_parser.yy | 4 +- tools/viewgar.1.in | 2 +- tools/viewgar.cpp | 11 +++--- 206 files changed, 2366 insertions(+), 1039 deletions(-) hooks/post-receive -- GiNaC -- a C++ library for symbolic computations From kisilv at maths.leeds.ac.uk Fri Feb 6 21:54:04 2009 From: kisilv at maths.leeds.ac.uk (Vladimir V. Kisil) Date: Fri, 06 Feb 2009 20:54:04 +0000 Subject: [GiNaC-devel] chinrem_gcd() bugfix (Was: Univariate GCD benchmark) In-Reply-To: <20090206065732.GA10220@metalica.kh.ua> References: <49884648.8070301@nikhef.nl> <20090205065312.GA30447@metalica.kh.ua> <498ADED3.2050708@ginac.de> <20090206065732.GA10220@metalica.kh.ua> Message-ID: <5989.1233953644@krein.leeds.ac.uk> >>>>> On Fri, 6 Feb 2009 08:57:32 +0200, Alexei Sheplyakov said: AS> Could you please try the patch below? It works for me! GiNaC from present head passed all test on my PC. Best wishes, Vladimir -- Vladimir V. Kisil email: kisilv at maths.leeds.ac.uk -- www: http://maths.leeds.ac.uk/~kisilv/ From varg at metalica.kh.ua Mon Feb 9 10:54:36 2009 From: varg at metalica.kh.ua (Alexei Sheplyakov) Date: Mon, 9 Feb 2009 11:54:36 +0200 Subject: [GiNaC-devel] [SCM] GiNaC -- a C++ library for symbolic computations branch, master, updated. release_1-4-0-177-g3627c2c In-Reply-To: <20090206121728.234B65B40F3@cebix.net> References: <20090206121728.234B65B40F3@cebix.net> Message-ID: <20090209095436.GA32167@metalica.kh.ua> Dear Jens, On Fri, Feb 06, 2009 at 01:17:27PM +0100, Jens Vollinga wrote: > - Log ----------------------------------------------------------------- > commit 3627c2c0f2fe8fe04816703c5fc6dad9c96fb0a6 > Author: Alexei Sheplyakov > Date: Fri Feb 6 08:57:32 2009 +0200 > > Fix chinese_remainder() so modular GCD actually works. Although the patch I've posted looks `obviously correct' and happens to work for you (and Vladimir), it would be nice to wait for feedback from Richard (or someone else using 64-bit architecture) before committing it. Best regards, Alexei -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 835 bytes Desc: Digital signature URL: From jensv at nikhef.nl Mon Feb 9 11:08:49 2009 From: jensv at nikhef.nl (Jens Vollinga) Date: Mon, 09 Feb 2009 11:08:49 +0100 Subject: [GiNaC-devel] [SCM] GiNaC -- a C++ library for symbolic computations branch, master, updated. release_1-4-0-177-g3627c2c In-Reply-To: <20090209095436.GA32167@metalica.kh.ua> References: <20090206121728.234B65B40F3@cebix.net> <20090209095436.GA32167@metalica.kh.ua> Message-ID: <499000B1.5030607@nikhef.nl> Hi, Alexei Sheplyakov schrieb: > Although the patch I've posted looks `obviously correct' and happens to work > for you (and Vladimir), it would be nice to wait for feedback from Richard > (or someone else using 64-bit architecture) before committing it. as you can see, commit 3627c2c0f2fe8fe04816703c5fc6dad9c96fb0a6 already exists ... I did read your remark > much more severe bug (in multivariate GCD code). I'll fix the test > after I find out what is wrong with chinrem_gcd(). and are waiting with the release, of course, until this issue is settled. Regards, Jens From varg at metalica.kh.ua Mon Feb 9 11:51:52 2009 From: varg at metalica.kh.ua (Alexei Sheplyakov) Date: Mon, 9 Feb 2009 12:51:52 +0200 Subject: [GiNaC-devel] chinese_remainder() bug versus x86_64 (Was: Univariate GCD benchmark) In-Reply-To: <20090206071222.GB10220@metalica.kh.ua> References: <49884648.8070301@nikhef.nl> <20090205065312.GA30447@metalica.kh.ua> <498ADED3.2050708@ginac.de> <498B5316.9050401@ginac.de> <20090206071222.GB10220@metalica.kh.ua> Message-ID: <20090209105152.GB32167@metalica.kh.ua> Dear Richard, Some time ago I wrote: > I've got another theory. There was a bug in chinese_remainder() function. > It's easy to spot it on 32-bit architecture, but not on 64-bit one. If my > theory is correct, the patch below should trigger the bug on 64-bit > architecture. Could you please try it (WITHOUT applying a patch which is > supposed to fix the bug, of course)? > > > Note: this patch is not supposed to be applied to the `official' repository. > > diff --git a/ginac/polynomial/primes_factory.h b/ginac/polynomial/primes_factory.h > index 093c973..d80bff7 100644 > --- a/ginac/polynomial/primes_factory.h > +++ b/ginac/polynomial/primes_factory.h > @@ -25,7 +25,7 @@ private: > cln::cl_I last; > // This ensures coefficients are immediate. > static const int immediate_bits = 8*sizeof(void *) - __alignof__(void *); > - static const long opt_hint = (1L << (immediate_bits >> 1)) - 1; > + static const long opt_hint = (1L << 14) - 1L; > public: > primes_factory() > { Any feedback? I'm sorry for hurrying you, but this issue needs to be clarified before the release. Best regards, Alexei -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 835 bytes Desc: Digital signature URL: From kreckel at ginac.de Mon Feb 9 20:22:47 2009 From: kreckel at ginac.de (Richard B. Kreckel) Date: Mon, 09 Feb 2009 20:22:47 +0100 Subject: [GiNaC-devel] chinese_remainder() bug versus x86_64 (Was: Univariate GCD benchmark) In-Reply-To: <20090209105152.GB32167@metalica.kh.ua> References: <49884648.8070301@nikhef.nl> <20090205065312.GA30447@metalica.kh.ua> <498ADED3.2050708@ginac.de> <498B5316.9050401@ginac.de> <20090206071222.GB10220@metalica.kh.ua> <20090209105152.GB32167@metalica.kh.ua> Message-ID: <49908287.9050303@ginac.de> Dear Alexei, Alexei Sheplyakov wrote: >> I've got another theory. There was a bug in chinese_remainder() function. >> It's easy to spot it on 32-bit architecture, but not on 64-bit one. If my >> theory is correct, the patch below should trigger the bug on 64-bit >> architecture. Could you please try it (WITHOUT applying a patch which is >> supposed to fix the bug, of course)? >> >> >> Note: this patch is not supposed to be applied to the `official' repository. >> >> diff --git a/ginac/polynomial/primes_factory.h b/ginac/polynomial/primes_factory.h >> index 093c973..d80bff7 100644 >> --- a/ginac/polynomial/primes_factory.h >> +++ b/ginac/polynomial/primes_factory.h >> @@ -25,7 +25,7 @@ private: >> cln::cl_I last; >> // This ensures coefficients are immediate. >> static const int immediate_bits = 8*sizeof(void *) - __alignof__(void *); >> - static const long opt_hint = (1L << (immediate_bits >> 1)) - 1; >> + static const long opt_hint = (1L << 14) - 1L; >> public: >> primes_factory() >> { > > Any feedback? I'm sorry for hurrying you, but this issue needs to be clarified > before the release. Oh, that patch above triggers the bug on 64-bit architectures, too! (I already emailed you off-list about this on Sunday.) For the record, here's what I did: $ git checkout master~9 This left me with "HEAD is now at 45b1e47... Implement modular multivariate GCD (based on chinese remaindering algorithm)." I applied you "patch", made check and it hang at the same point that has been reported before by Jens and Vladimir on 32-bit systems. regards -richy. -- Richard B. Kreckel From varg at metalica.kh.ua Mon Feb 16 15:23:16 2009 From: varg at metalica.kh.ua (Alexei Sheplyakov) Date: Mon, 16 Feb 2009 16:23:16 +0200 Subject: [GiNaC-devel] Univarite GCD timing correction In-Reply-To: <499000B1.5030607@nikhef.nl> References: <20090206121728.234B65B40F3@cebix.net> <20090209095436.GA32167@metalica.kh.ua> <499000B1.5030607@nikhef.nl> Message-ID: <20090216142316.GA12226@metalica.kh.ua> Hi, On Mon, Feb 09, 2009 at 11:08:49AM +0100, Jens Vollinga wrote: > I did read your remark > > > much more severe bug (in multivariate GCD code). I'll fix the test > > after I find out what is wrong with chinrem_gcd(). > > and are waiting with the release, of course, until this issue is settled. On Mon, Feb 09, 2009 at 08:22:47PM +0100, Richard B. Kreckel wrote: > For the record, here's what I did: > $ git checkout master~9 > This left me with "HEAD is now at 45b1e47... Implement modular > multivariate GCD (based on chinese remaindering algorithm)." I applied > you "patch", made check and it hang at the same point that has been > reported before by Jens and Vladimir on 32-bit systems. Now I believe my theory and the fix for poly_cra() are correct. Please find the patch fixing the univarite GCD timing below. From: Alexei Sheplyakov Subject: [PATCH] Univariate GCD timing: use sr_gcd when appropriate. The benchmark consists of two parts: 1) timing of different GCD calculation methods (i.e. subresultant PRS, heuristic, chinese remaindering). 2) timing of different implementations of the same method. The purpose is to find out how (in)efficient GiNaC::ex is as a representation of (univariate) polynomials (as a side note, the result is a bit depressing -- using coefficient vector instead of GiNaC:ex makes GCD calculation 50x -- 1000x faster). Now GiNaC uses modular (chinese remaindering) GCD by default, so part 2) got broken, i.e. instead of (intended) timings a) (heuristic, GiNaC::ex) versus (heuristic, coefficient vector) b) (PRS, GiNaC::ex) versus (PRS, coefficient vector) one gets a') (heuristic, GiNaC::ex) versus (heuristic, coefficient vector) b') (chinese remaindering, GiNaC::ex) versus (PRS, coefficient vector) Set the gcd_options::use_sr_gcd to restore the meaning of the benchmark. Note: this patch does not affect the library proper. --- check/time_uvar_gcd.cpp | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/check/time_uvar_gcd.cpp b/check/time_uvar_gcd.cpp index c65c515..fe75897 100644 --- a/check/time_uvar_gcd.cpp +++ b/check/time_uvar_gcd.cpp @@ -1780,7 +1780,8 @@ struct ex_sr_gcd_test const upoly& g_check; unsigned options; ex_sr_gcd_test(const ex& a_, const ex& b_, const upoly& g_) : - a(a_), b(b_), g(0), g_check(g_), options(gcd_options::no_heur_gcd) + a(a_), b(b_), g(0), g_check(g_), options(gcd_options::no_heur_gcd | + gcd_options::use_sr_gcd) { } inline void run() -- 1.5.6.5 Best regards, Alexei -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 835 bytes Desc: Digital signature URL: From varg at metalica.kh.ua Mon Feb 16 15:24:15 2009 From: varg at metalica.kh.ua (Alexei Sheplyakov) Date: Mon, 16 Feb 2009 16:24:15 +0200 Subject: [GiNaC-devel] [PATCH] Polished NEWS a little bit. Message-ID: <20090216142415.GA13089@metalica.kh.ua> --- NEWS | 7 ++++--- 1 files changed, 4 insertions(+), 3 deletions(-) diff --git a/NEWS b/NEWS index c8b40f9..31bacaf 100644 --- a/NEWS +++ b/NEWS @@ -2,11 +2,12 @@ This file records noteworthy changes. 1.5.0 () * Added polynomial factorization. -* Added an additional (recursive descent) expression parser. +* New, faster (recursive descent) expression parser. * Faster GCD computation. * gcd() now allows the user to override (some of the) heuristics. -* Replaced custum RTTI by standard C++ RTTI. -* Definition of archiving methods now optional when declaring a new GiNaC class. +* Writing extensions classes is simpler now: + - Replaced custom RTTI by standard C++ RTTI. + - Definition of archiving methods now optional when declaring a new GiNaC class. * Fixed recursion in polynomial divide that caused a significant slowdown in sqrfree(). * Improved lsolve() of systems containing non-numeric coefficients. -- 1.5.6.5 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 835 bytes Desc: Digital signature URL: From varg at metalica.kh.ua Mon Feb 16 15:28:57 2009 From: varg at metalica.kh.ua (Alexei Sheplyakov) Date: Mon, 16 Feb 2009 16:28:57 +0200 Subject: [GiNaC-devel] Release often, release early Message-ID: <20090216142857.GA13161@metalica.kh.ua> Dear GiNaC developers, I think we can release now unless someone has a very urgent patch or a bug report. Best regards, Alexei -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 835 bytes Desc: Digital signature URL: From jensv at nikhef.nl Mon Feb 16 16:00:30 2009 From: jensv at nikhef.nl (Jens Vollinga) Date: Mon, 16 Feb 2009 16:00:30 +0100 Subject: [GiNaC-devel] Univarite GCD timing correction In-Reply-To: <20090216142316.GA12226@metalica.kh.ua> References: <20090206121728.234B65B40F3@cebix.net> <20090209095436.GA32167@metalica.kh.ua> <499000B1.5030607@nikhef.nl> <20090216142316.GA12226@metalica.kh.ua> Message-ID: <49997F8E.6030307@nikhef.nl> Hi Alexei, Alexei Sheplyakov schrieb: > 2) timing of different implementations of the same method. The purpose > is to find out how (in)efficient GiNaC::ex is as a representation > of (univariate) polynomials (as a side note, the result is a bit > depressing -- using coefficient vector instead of GiNaC:ex makes > GCD calculation 50x -- 1000x faster). is this the difference between GiNaC::ex and non-GiNaC::ex access or between GiNaC::{mul,add} and std::vector representation? And is this difference for a dense or non-dense representation in a vector? Just curious. Maybe if automatic conversion between mul/add and a dedicated polynomial class is restricted to happen only for gcd calculations it is very beneficial. Regards, Jens From git at ginac.de Tue Feb 17 14:34:24 2009 From: git at ginac.de (Jens Vollinga) Date: Tue, 17 Feb 2009 14:34:24 +0100 (CET) Subject: [GiNaC-devel] [SCM] GiNaC -- a C++ library for symbolic computations branch, master, updated. release_1-4-0-183-gf529b4d Message-ID: <20090217133424.B16225B4054@cebix.net> This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "GiNaC -- a C++ library for symbolic computations". The branch, master has been updated via f529b4d90e810d5b2a8d463b6327824805a87db7 (commit) from fc16effeefb35845d77d98b2173160131bafa9b3 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- commit f529b4d90e810d5b2a8d463b6327824805a87db7 Author: Jens Vollinga Date: Tue Feb 17 14:38:17 2009 +0100 Added release date. ----------------------------------------------------------------------- Summary of changes: NEWS | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) hooks/post-receive -- GiNaC -- a C++ library for symbolic computations From git at ginac.de Tue Feb 17 14:44:01 2009 From: git at ginac.de (Jens Vollinga) Date: Tue, 17 Feb 2009 14:44:01 +0100 (CET) Subject: [GiNaC-devel] [SCM] GiNaC -- a C++ library for symbolic computations branch, master, updated. release_1-4-0-185-gcbba7a5 Message-ID: <20090217134401.5A2AA5B4054@cebix.net> This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "GiNaC -- a C++ library for symbolic computations". The branch, master has been updated via cbba7a5eb9d33003c081a8017dec7da3aa990571 (commit) via 4f2cf6aebc213c200b98fde6adb7133e8688530d (commit) from f529b4d90e810d5b2a8d463b6327824805a87db7 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- commit cbba7a5eb9d33003c081a8017dec7da3aa990571 Author: Alexei Sheplyakov Date: Mon Feb 16 16:23:16 2009 +0200 Univariate GCD timing: use sr_gcd when appropriate. The benchmark consists of two parts: 1) timing of different GCD calculation methods (i.e. subresultant PRS, heuristic, chinese remaindering). 2) timing of different implementations of the same method. The purpose is to find out how (in)efficient GiNaC::ex is as a representation of (univariate) polynomials (as a side note, the result is a bit depressing -- using coefficient vector instead of GiNaC:ex makes GCD calculation 50x -- 1000x faster). Now GiNaC uses modular (chinese remaindering) GCD by default, so part 2) got broken, i.e. instead of (intended) timings a) (heuristic, GiNaC::ex) versus (heuristic, coefficient vector) b) (PRS, GiNaC::ex) versus (PRS, coefficient vector) one gets a') (heuristic, GiNaC::ex) versus (heuristic, coefficient vector) b') (chinese remaindering, GiNaC::ex) versus (PRS, coefficient vector) Set the gcd_options::use_sr_gcd to restore the meaning of the benchmark. Note: this patch does not affect the library proper. commit 4f2cf6aebc213c200b98fde6adb7133e8688530d Author: Alexei Sheplyakov Date: Mon Feb 16 16:24:15 2009 +0200 Polished NEWS a little bit. ----------------------------------------------------------------------- Summary of changes: NEWS | 7 ++++--- check/time_uvar_gcd.cpp | 3 ++- 2 files changed, 6 insertions(+), 4 deletions(-) hooks/post-receive -- GiNaC -- a C++ library for symbolic computations From git at ginac.de Tue Feb 17 17:30:59 2009 From: git at ginac.de (Jens Vollinga) Date: Tue, 17 Feb 2009 17:30:59 +0100 (CET) Subject: [GiNaC-devel] [SCM] GiNaC -- a C++ library for symbolic computations tag, release_1-5-0, created. release_1-4-0-185-gcbba7a5 Message-ID: <20090217163059.E86AE5B4054@cebix.net> This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "GiNaC -- a C++ library for symbolic computations". The tag, release_1-5-0 has been created at cbba7a5eb9d33003c081a8017dec7da3aa990571 (commit) - Log ----------------------------------------------------------------- commit cbba7a5eb9d33003c081a8017dec7da3aa990571 Author: Alexei Sheplyakov Date: Mon Feb 16 16:23:16 2009 +0200 Univariate GCD timing: use sr_gcd when appropriate. The benchmark consists of two parts: 1) timing of different GCD calculation methods (i.e. subresultant PRS, heuristic, chinese remaindering). 2) timing of different implementations of the same method. The purpose is to find out how (in)efficient GiNaC::ex is as a representation of (univariate) polynomials (as a side note, the result is a bit depressing -- using coefficient vector instead of GiNaC:ex makes GCD calculation 50x -- 1000x faster). Now GiNaC uses modular (chinese remaindering) GCD by default, so part 2) got broken, i.e. instead of (intended) timings a) (heuristic, GiNaC::ex) versus (heuristic, coefficient vector) b) (PRS, GiNaC::ex) versus (PRS, coefficient vector) one gets a') (heuristic, GiNaC::ex) versus (heuristic, coefficient vector) b') (chinese remaindering, GiNaC::ex) versus (PRS, coefficient vector) Set the gcd_options::use_sr_gcd to restore the meaning of the benchmark. Note: this patch does not affect the library proper. ----------------------------------------------------------------------- hooks/post-receive -- GiNaC -- a C++ library for symbolic computations From jensv at nikhef.nl Tue Feb 17 18:21:09 2009 From: jensv at nikhef.nl (Jens Vollinga) Date: Tue, 17 Feb 2009 18:21:09 +0100 Subject: [GiNaC-devel] Release GiNaC 1.5.0 Message-ID: <499AF205.2070505@nikhef.nl> Hi everybody, GiNaC 1.5.0 is out and available. The changes are: * Added polynomial factorization. * New, faster (recursive descent) expression parser. * Faster GCD computation. * gcd() now allows the user to override (some of the) heuristics. * Writing extensions classes is simpler now: - Replaced custom RTTI by standard C++ RTTI. - Definition of archiving methods now optional when declaring a new GiNaC class. * Fixed recursion in polynomial divide that caused a significant slowdown in sqrfree(). * Improved lsolve() of systems containing non-numeric coefficients. * Removed implicit conversions from cl_N to numeric. * Improved configuration and compatibility. This is a new branch that introduces some incompatibilities on the source code level! If you have defined your own GiNaC classes, you will have to change their definitions slightly (cf. section 6.5.6 in http://www.ginac.de/tutorial/Adding-classes.html#Adding-classes). As always, this release can be downloaded from http://www.ginac.de/Download.html Best wishes, Jens From git at ginac.de Tue Feb 17 17:27:23 2009 From: git at ginac.de (Jens Vollinga) Date: Tue, 17 Feb 2009 17:27:23 +0100 (CET) Subject: [GiNaC-devel] [SCM] GiNaC -- a C++ library for symbolic computations branch, ginac_1-5, created. release_1-4-0-185-gcbba7a5 Message-ID: <20090217162723.97FB85B4054@cebix.net> This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "GiNaC -- a C++ library for symbolic computations". The branch, ginac_1-5 has been created at cbba7a5eb9d33003c081a8017dec7da3aa990571 (commit) - Log ----------------------------------------------------------------- commit cbba7a5eb9d33003c081a8017dec7da3aa990571 Author: Alexei Sheplyakov Date: Mon Feb 16 16:23:16 2009 +0200 Univariate GCD timing: use sr_gcd when appropriate. The benchmark consists of two parts: 1) timing of different GCD calculation methods (i.e. subresultant PRS, heuristic, chinese remaindering). 2) timing of different implementations of the same method. The purpose is to find out how (in)efficient GiNaC::ex is as a representation of (univariate) polynomials (as a side note, the result is a bit depressing -- using coefficient vector instead of GiNaC:ex makes GCD calculation 50x -- 1000x faster). Now GiNaC uses modular (chinese remaindering) GCD by default, so part 2) got broken, i.e. instead of (intended) timings a) (heuristic, GiNaC::ex) versus (heuristic, coefficient vector) b) (PRS, GiNaC::ex) versus (PRS, coefficient vector) one gets a') (heuristic, GiNaC::ex) versus (heuristic, coefficient vector) b') (chinese remaindering, GiNaC::ex) versus (PRS, coefficient vector) Set the gcd_options::use_sr_gcd to restore the meaning of the benchmark. Note: this patch does not affect the library proper. commit 4f2cf6aebc213c200b98fde6adb7133e8688530d Author: Alexei Sheplyakov Date: Mon Feb 16 16:24:15 2009 +0200 Polished NEWS a little bit. commit f529b4d90e810d5b2a8d463b6327824805a87db7 Author: Jens Vollinga Date: Tue Feb 17 14:38:17 2009 +0100 Added release date. commit fc16effeefb35845d77d98b2173160131bafa9b3 Author: Jens Vollinga Date: Fri Feb 6 16:49:47 2009 +0100 Adjusted NEWS and INSTALL documentation. commit 0d22af8982798509662a897ce72f546fe2149d0c Author: Jens Vollinga Date: Fri Feb 6 16:35:22 2009 +0100 Missed to change one date in function.pl. commit 2251ede3f4b3e7066f83fbedba53181c03f633f7 Author: Jens Vollinga Date: Fri Feb 6 16:24:58 2009 +0100 Changed name of debugging macro (to avoid warning cause by multiple definition). commit bf08e105894751acc66f337074be6a5b9e738220 Author: Jens Vollinga Date: Fri Feb 6 16:22:58 2009 +0100 Fixed returning of test result (++result was +result). commit 1602530f716ba1d425a0667b897182b99c374823 Author: Jens Vollinga Date: Fri Feb 6 16:07:10 2009 +0100 Prettified source code. - Added copyright and GPL licencing to new files. - Increased year to 2009. - Changed guarding macros in header to uniform pattern without leading or trailing __ (double underscores). - Put includes of system wide header consistently below own includes (help a tiny bit to clarify dependencies). commit 3627c2c0f2fe8fe04816703c5fc6dad9c96fb0a6 Author: Alexei Sheplyakov Date: Fri Feb 6 08:57:32 2009 +0200 Fix chinese_remainder() so modular GCD actually works. commit a3a0f8b23bb70802cb0fc952cafdc2223c892fe9 Author: Jens Vollinga Date: Fri Feb 6 13:13:06 2009 +0100 Automake now needs to be version >=1.8. Older versions like 1.7.9 do not create the directory m4 in a VPATH build. commit 80b1c3e0ee0e465d56e5c76bef4e52ef2dbc5197 Author: Jens Vollinga Date: Thu Feb 5 10:54:21 2009 +0100 Renamed files *.tcc and *.hpp to *.h. commit b9dc3d71083fe1a2f90a34db24b57b06ad51ebde Author: Jens Vollinga Date: Tue Feb 3 13:50:33 2009 +0100 Fixed compile errors introduced in previous commit 45b1e47372090352ac5af655b32473df2abab23b. commit 45b1e47372090352ac5af655b32473df2abab23b Author: Alexei Sheplyakov Date: Mon Jan 19 08:45:38 2009 +0200 Implement modular multivariate GCD (based on chinese remaindering algorithm). Both algorithm and implementation are a bit inefficient: * algorithm does not make use of sparseness of inputs (and most of multivariate polynomials are quite sparse) * GiNaC's expressions are essentially immutable. Thus some simple operations (i.e. multiplying a polynomial by an element of the base ring) are prohibitively expensive. * All numbers (i.e. GiNaC::numeric objects) are heap allocated. Still it's much faster (~5x on bivariate polynomials, ~100x on 3-variate ones) than (subresultant) PRS algorithm, so gcd() uses modular algorithm by default. commit 3f0b0165865bbb297901e9542fced88a0e32298e Author: Alexei Sheplyakov Date: Mon Jan 19 08:44:36 2009 +0200 Improve (fix?) smod: now it really converts into symmetric representation... ... instead of clumsy convention inspirited by some proprietary CAS. commit e79c1f6f914b7be886a19c8d7cdd3603405cda2a Author: Alexei Sheplyakov Date: Mon Jan 19 08:43:50 2009 +0200 Fix copy-paste error in GINACLIB_MICRO_VERSION. commit 38f3143eee71d942f40ab47f5a561dc9736203fc Author: Jens Vollinga Date: Thu Jan 8 10:26:50 2009 +0100 Fixed bug in binomial(). binomial(n,0) erroneously returned 0. commit 4c47ecd9caa39ba1a31f5294e395fcbdf2006431 Author: Jens Vollinga Date: Thu Dec 18 12:19:35 2008 +0100 Small fixes to avoid compile warnings (-Wall). commit a12c1d88131c5a301d35767f0c4c947064703418 Author: Jens Vollinga Date: Thu Dec 18 11:10:50 2008 +0100 Fixed bug in multivariate factorization. Fractional numerical content was not extracted and led to a not so finite running behavior. Added new checks for that bug. Added static keywords to hide debugging output operators. commit 7b68fe1d835d84030d4a351c1a3c7665dc15e7e3 Author: Jens Vollinga Date: Mon Dec 1 10:26:38 2008 +0100 Added new items. commit 58491538f7362529b3eaa1bcffcab3e9c0f0d049 Author: Alexei Sheplyakov Date: Mon Dec 1 10:13:12 2008 +0100 [PATCH] [build] Simplify generation of ginac/version.h commit 481e3e83f6b71d6639dd5c3fbd3c0d1e1ac18328 Author: Alexei Sheplyakov Date: Mon Dec 1 10:12:25 2008 +0100 [PATCH] Fix GiNaC library version information. The libtool naming scheme cannot guarantee that on all systems, the numbering is consecutive. It only guarantees that it is increasing. This doesn't matter, though: there is not incurred cost for numbers that are omitted, except for shrinking the available space of leftover numbers. Not something we need to worry about yet. ;-) On the other hand, tricks which we were using to make version numbers consecutive on GNU/Linux break versioning on other OSes. commit c277943ace48d2f22f7016ba9439ff7cb949a231 Author: Jens Vollinga Date: Mon Dec 1 09:54:53 2008 +0100 Fixed a problem in polynomial divide by deactivating a recursion that lead to a significant slowdown in sqrfree() and sometimes to a infinite loop. commit 6ddfb1a594386a48ab627ef7237e897535235593 Author: Jens Vollinga Date: Fri Nov 14 12:00:52 2008 +0100 Added section about factor(). Made appropriate changes at other places. commit dcce72e85f936117b39774a839ec1d76add66aec Author: Jens Vollinga Date: Thu Nov 13 16:36:02 2008 +0100 Added many comments. commit 2b0ad5c381dc081cc4066b0c5f939f5169ad9ab3 Author: Jens Vollinga Date: Thu Nov 13 11:13:05 2008 +0100 Fixed lots of bugs in factor_multivariate(). factor_univariate() takes now the content of the polynomial into accout when choosing a prime. It also returns the chosen prime. This supports the factor_multivariate() code. Polynomials are expanded before calling factor_sqrfree(). This avoids problems with some input polynomials. Added static qualifiers to all hidden functions. commit a17a77e5c3d4ec2a92804debac65c75921f0156d Author: Jens Vollinga Date: Tue Nov 11 10:33:29 2008 +0100 Fixed a bug in squarefree(). Some polynomials were erroneously classified as square free (e.g. x^prime+1). Fixed a bug in multivar_diophant() causing sporadically an infinite loop. Improved lifting bound code. Univariate lifting can now use a cache for the modular factors. At the moment, this gives no measurable speed gain. commit edc92b7a463993da62357fb4afad053e8c6d0771 Author: Jens Vollinga Date: Mon Nov 10 13:38:11 2008 +0100 Added modular square free factorization. Completed distinct degree factorization. Univariate polynomial factorization uses now upoly. Merged class Partition and function split into class factor_partition. commit 22bf8270163ec9ec11f37c79957e18d6e6e163cd Author: Jens Vollinga Date: Thu Nov 6 14:18:01 2008 +0100 Stupid error: did the revert on the wrong branch (master instead of ginac_1-4). Revert "Revert "[portability] GiNaC::compile_ex works on OpenBSD now."" This reverts commit a6854a8a0f1e5db722320f5d7ccb9097053500cf. commit a6854a8a0f1e5db722320f5d7ccb9097053500cf Author: Jens Vollinga Date: Thu Nov 6 14:13:54 2008 +0100 Revert "[portability] GiNaC::compile_ex works on OpenBSD now." This reverts commit 375a7aa1f13fa6061c278eb2c2447fd91521b45d. commit 9d92d4b442fc4c1a95685884be4ba0494cd02bbe Author: Jens Vollinga Date: Thu Nov 6 14:11:02 2008 +0100 Univariate Hensel lifting now uses upoly. Changed q_matrix code. commit e342f91c239e89839fdbe643957595b5f598c628 Author: Paul Irofti Date: Tue Nov 4 17:55:34 2008 +0300 Equip ginac-examples.texi with directory entry for info. commit 375a7aa1f13fa6061c278eb2c2447fd91521b45d Author: Alexei Sheplyakov Date: Mon Nov 3 19:17:16 2008 +0300 [portability] GiNaC::compile_ex works on OpenBSD now. * acinclude.m4: check for dlopen() in libdl and in libc itself. Thanks to Paul Irofti for a bug report and a suggestion. commit 6488232432c883422104915c65b89f194fc0c2ee Author: Alexei Sheplyakov Date: Mon Nov 3 17:34:29 2008 +0300 [build] Set correct rpath for linking with CLN... ... so users won't get 'error while loading shared libraries: no such file or directory'. Also embed rpath into pkg-config meta data, so g++ `pkg-config --cflags --libs ginac` foo.cc actually works without any additional effort from the user side. commit d625a28c3def007a9d2d5108141a6f6a4889bf9d Author: Alexei Sheplyakov Date: Thu Oct 23 17:48:14 2008 +0400 [bugfix] integer_cra: check if arguments contain at least 2 moduli While at it, also fix exam_cra so it does not produce pointless inputs. commit 44fa38df264efa7a87beb59afc4664595de8ab48 Author: Alexei Sheplyakov Date: Tue Oct 21 10:09:33 2008 +0400 exam_cra: explicitly #include . This should make g++ 4.3 happy. commit 556ea59d4be5f0e2e8d3760501b8b9cb8587c1ec Author: Jens Vollinga Date: Wed Nov 5 13:56:53 2008 +0100 Changed debugging facilities in factor.cpp. commit 40d2f5d1ddacf71991adb447b163a19136ee2179 Author: Jens Vollinga Date: Wed Nov 5 11:31:35 2008 +0100 Fixed some minor spelling errors. commit 931ece4838fcef7b9ec71761d224e2e1cd11a89d Author: Jens Vollinga Date: Wed Nov 5 11:22:19 2008 +0100 Changed code from using cl_UP_MI to using umodpoly. The cl_UP_MI interface was inconvenient to use and caused several very difficult bugs (some were still unresolved before changing to umodpoly!). Fixed severe bug in multivariate factorization. The condition that all modular factors should be relatively prime in the base ring was violated. This caused the factorization sometimes to go into an infinite loop. commit e989719ca767691eb75b34785baaaed716ea2624 Author: Jens Vollinga Date: Mon Nov 3 15:50:31 2008 +0100 Added code for distinct degree factorization. commit 4fb48e28063e08c613a773378cfa5de608560a84 Author: Alexei Sheplyakov Date: Sun Oct 19 20:21:33 2008 +0400 tutorial: simplify the instructions on writing extension classes. Don't mention (un)archiving while describing the `mystring' class (the minimalistic extension class), so readers have less chances to get confused. commit d327f3f00c66a79d42855939866047b3e8caa630 Author: Alexei Sheplyakov Date: Sun Oct 19 19:39:30 2008 +0400 Don't force every algebraic class to implement archiving/unarchiving. So people who don't use (un)archiving don't need to bother with it. commit 434e5582627a91aa4d8fdb5156d975482a7f350c Author: Alexei Sheplyakov Date: Fri Oct 17 17:57:27 2008 +0400 tutorial: don't mention custom RTTI any more (as it does not exist). commit 8fdf123fe6dac43ad7b8020d7bb7446c51cf75e7 Author: Alexei Sheplyakov Date: Thu Oct 16 15:43:32 2008 +0400 symbol: make get_domain() a virtual method, remove symbol::domain. This cuts yet another 4 bytes from GiNaC::symbol. While at it, fix a memory leak in ginsh. commit 94e5076a9ad0d142ee4604e9b078a10083efd24c Author: Alexei Sheplyakov Date: Thu Oct 16 15:43:32 2008 +0400 symbol: don't bother to set TeX name if user did not specified one. Same for the usual name. As a result we use less memory (and the output is exactly the same). commit 32209e57010f19f080cc25e527347bcaa36053ec Author: Alexei Sheplyakov Date: Fri Oct 17 14:56:54 2008 +0400 symbol: remove return_type_tinfo() and return_type() (shrink symbol by 8 bytes) Bloating symbol to the state sizeof(symbol) == 64 is not appreciated at all. If someone needs/wants non-commutative symbols or other fancy stuff, please derive from class symbol and do whatever you want. commit def26469ff96228c66e877bb5594e7d9a24b638f Author: Alexei Sheplyakov Date: Fri Oct 17 13:41:01 2008 +0400 Wipe out remnants of custom RTTI. Custom RTTI considered harmful, final part. commit 09988aee53a2bfef87fc887a434b4c78d6326c47 Author: Alexei Sheplyakov Date: Wed Oct 15 15:32:11 2008 +0400 registered_class_info: use typeid() instead of tinfo_static. (Custom RTTI considered harmful, part 5). Since custom RTTI is going to be removed, registered_class_info needs to be re-organazied. Now tinfo_key is a (const) pointer to std::type_info. commit 12fefbca9b424cb8e9ae05d83883b96e17c7b96e Author: Alexei Sheplyakov Date: Fri Oct 17 13:15:03 2008 +0400 A better return_type_tinfo() mechanism. return_type_tinfo() is used in order to distingish between non-commutative objects of different type. However, often it's necessary to distingish between non-commutative objects of the same type, for example, between gamma matrices with different representation label. return_type_tinfo() does not provide any clean way to do that. Hence, introduce return_type_t type which holds representation label along with type information, and use it for return_type_tinfo(). commit b573b0146341709649f373e0fc5c0d440877ebaf Author: Alexei Sheplyakov Date: Wed Oct 15 15:32:11 2008 +0400 calchash(): use type_info::name() instead of tinfo(). Custom RTTI considered harmful, part 4. The hash value of the object of different types should be different whenever possible. Hence calcash() needs a unique per type number. Previously we used tinfo_key for this. typeinfo::name() (a *pointer* to implementation dependent string) is also unique for each class, so it's just as good as tinfo() is. commit e858ebe524f9beac33d492b9a4e614666819c3ab Author: Alexei Sheplyakov Date: Wed Oct 15 15:32:11 2008 +0400 indexed::eval: use standard C++ RTTI. Custom RTTI considered harmful, part 3. commit 11fcbe7ea462936b79807a1f12273e5685f3f744 Author: Alexei Sheplyakov Date: Wed Oct 15 15:32:11 2008 +0400 basic, expairseq: use standard C++ RTTI in compare(), is_equal(), match(), etc. Custom RTTI considered harmful, part 2. * basic.cpp: use standard C++ RTTI in compare(), is_equal(), operator=(), match(). * expairseq.cpp: use standard C++ RTTI in match(), make_flat(), construct_from_2_ex(). commit e9b5729311fcd5572d806f5df2e645e1845603e5 Author: Alexei Sheplyakov Date: Wed Oct 15 15:32:11 2008 +0400 is_exactly_a: use typeid() to check the type of expression. Custom RTTI considered harmful, part 1. Custom run time type information (RTTI) system implemented in GiNaC have several serious drawbacks, such as 1. It makes writing GiNaC classes unnecessary cumbersome. 2. It wastes sizeof(void *) bytes per object, for small objects like symbol, numeric, etc. this overhead is considerable. It turns out that GiNaC's RTTI is not any faster than the standard one (at least on GNU/Linux and Solaris with GNU C++ library and compiler). So, GiNaC RTTI have no reasons to exit any more. commit ce9053c15affb2a1a99d1157b85266d70aec601b Author: Alexei Sheplyakov Date: Wed Oct 15 10:16:07 2008 +0400 ptr.h: use unsigned int to store reference counts (in order to save memory). We'll hardly ever get more than 2^32 references to the same object. So using size_t to store reference count only wastes 4 bytes per object (on 64-bit architecture). Use unsigned int instead. commit c7d9b624cb4bd5658a36fbcac2f73dbdb99edd5f Author: Alexei Sheplyakov Date: Sun Oct 19 21:27:14 2008 +0400 Rewritten heuristic and PRS GCD for univariate polynomials, added benchmark. Using a better data structure for univariate polynomials makes GCD 10 -- 300 times faster (and less memory hungry). commit 47b7f9c9b4a5bd91c7c83b12bac8481b55bf4b92 Author: Alexei Sheplyakov Date: Tue Oct 14 10:44:07 2008 +0400 polynomial: introduce a helper function to divide polynomial by ring element. commit 55fcb39a1209898ec43694f7e25ffb4572b0c4d1 Author: Alexei Sheplyakov Date: Tue Oct 14 10:37:42 2008 +0400 mod_gcd: naive hack to chose a 'good' prime (to speed up gcd computation). commit 62923ac249c7e4f7e824bc37030ac79bab3675f3 Author: Alexei Sheplyakov Date: Mon Sep 29 09:58:35 2008 +0400 [bugfix] remainder_in_ring: using exact division is plain wrong. commit d5c76f155cfbd25ccfd14735b6d1041e23214a86 Author: Alexei Sheplyakov Date: Mon Sep 29 09:53:46 2008 +0400 [bugfix] normalize_in_ring: don't set the leading coefficient to 1. The coefficient ring is not a field, so the leading coefficient don't have to be 1. commit ceb63120f43b41b62dcb0328231a3137d666161b Author: Alexei Sheplyakov Date: Thu Sep 25 13:19:57 2008 +0400 [trivial] excompiler.cpp: shut up some silly compiler warnings. GCC warns about 'comparison between signed and unsigned integer expressions'. In this case such comparison is harmless, but still it's a bit annoying. commit a377cee53b71348235ec36f83afeced7e10288a8 Merge: 2a5d912dc9407c6bd1dbee6cb99cfdc206c4e42c 546bababce8ef2b3c5ed3011cb7e49bd78016844 Author: Jens Vollinga Date: Tue Sep 30 11:47:25 2008 +0200 Merge branch 'master' of git://ffmssmsc.jinr.ru:443/varg/ginac commit 2a5d912dc9407c6bd1dbee6cb99cfdc206c4e42c Author: Jens Vollinga Date: Mon Sep 29 17:38:46 2008 +0200 Replaced class UniPoly by cl_UP_MI. commit 1b735625b2759c1627046f9cb1baf834f4d26f5d Author: Jens Vollinga Date: Fri Sep 26 11:07:02 2008 +0200 - Added options argument to factor(). Added flag factor_options::all that lets factor() act on all polynomial subexpressions. - Added more comments. commit 546bababce8ef2b3c5ed3011cb7e49bd78016844 Author: Alexei Sheplyakov Date: Sat Sep 20 23:18:46 2008 +0400 Implemented modular GCD algorithm for univariate polynomials. commit 8c732512ca284f2a586694c7c33f1a0a4a68cef7 Author: Alexei Sheplyakov Date: Sun Sep 14 07:13:01 2008 +0400 Wipe out the old (bison/flex generated) parser. Bison generated parser has a number of problems: 1. Bad performance. Parsing a sum seems to be O(N^{2 + a}) (a > 0). For example, parsing a sum (actually, a univariate polynomial) of 32768 terms takes about 90 sec. on my box, parsing a sum of 10^6 terms takes "eternity". 2. The user is expected to provide list of all symbols in the expression. Often this is very annoying (and useless), sometimes it is not possible at all. 3. Parser is not reentrant (bison *can* produce reentrant parsers, but that won't solve other problems). 4. Parser is difficult to extend. Since the new parser handles almost everything (useful) as the old one, let's remove the latter. commit b84032466e31ff23d4be3b81a3f535b2c70202e5 Author: Alexei Sheplyakov Date: Sun Sep 14 06:57:21 2008 +0400 check: time_parser.cpp: don't run the same benchmark twice. Since ex(const string&, lst&) ctor uses the new parser now comparing its performance (and result) with one of direct invocation of the parser is pointless. commit 6f64b39dd25e4d2dcc869995b3d19724fa72afa6 Author: Alexei Sheplyakov Date: Sun Sep 14 06:41:12 2008 +0400 Document the new parser, provide an example. commit 95bec2b8af126412b2e27b51e6bfd8d9ab18d5d7 Author: Alexei Sheplyakov Date: Sun Sep 14 06:24:29 2008 +0400 Use the new parser in the ex(const string&, lst&) ctor. Note: this is certainly not the optimal way to use the parser. It's provided for backward compatibility only. commit 3324b2f0f035490940b1a9d7cf5dc210776f6d87 Author: Alexei Sheplyakov Date: Sun Sep 14 06:01:53 2008 +0400 Parser can parse (some) floating point numbers now. commit 1261c54df6548cf558405a118b2134805f63376d Author: Alexei Sheplyakov Date: Sun Sep 14 03:26:33 2008 +0400 parser: add necessary checks to operator() to stop accepting nonsense. Since the parser is recursive parse_* methods (in particular, parse_binop_rhs()) does NOT check if the last unparsed token is valid. Thus parse_expression() stops if it encounters an unknown token. That's why parser::operator() needs to make sure nothing is left in the input stream. commit d4593e1981a168677f98e4d3b098696bd31088e2 Author: Alexei Sheplyakov Date: Sun Sep 14 02:36:16 2008 +0400 [bugfix] parser::parse_literal_expr(): don't forget to consume the token... ... so parser won't process it twice (and get either spurious error or wrong result). commit 05157f89a3db97fff79e33fd53156b380107011f Author: Alexei Sheplyakov Date: Sun Sep 14 03:19:05 2008 +0400 [bugfix]: parser::parse_unary_expr() parses '-a-b' correctly now. Also added regression test. commit dbe5029ed72f406f45ec2a9d3584a828653ab34a Author: Alexei Sheplyakov Date: Sat Sep 13 05:12:31 2008 +0400 ginac.h: include parser.hpp commit 14d8318d10eb608300e006af3bc261690c14d041 Author: Alexei Sheplyakov Date: Sat Sep 13 04:55:23 2008 +0400 parser: change order of the constructor optional arguments. Functions/methods having multiple optional arguments are not very convenient to use in C++ (to put it mildly). Shuffle parser ctor arguments so not so frequently used argument is the last one. commit ef06261c6354bea6d35e8bcdb89806056d4cccb9 Author: Alexei Sheplyakov Date: Sat Sep 13 04:40:12 2008 +0400 parser: allow read/write access to symbol table and strictness. Intended usage: parser reader; ifstream input_file1, input_file2; // read the first file... ex e1 = reader(input_file1); // ... add extra entry into the symbol table used by parser symbol x; parser.get_syms()["x"] = x; // Disable the parser to introduce new symbols, e.g. to ensure the expression // in input_file2 contains the same symbols as e1 (read from input_file1). parser.strict = true; ex e2; try { e2 = reader(input_file2); } catch (...) { abort(); } commit 58a84c0adac7cbaa63a50c06815aed9c7a0bcdcc Author: Alexei Sheplyakov Date: Sat Sep 13 04:30:22 2008 +0400 parser: map input strings onto arbitrary expressions (not only symbols). So it's possible to make abbreviations, e.g. symbol x; symtab table; table["x"] = x + log(x) + 1; parser reader(table); ex e = reader("1 + x^2 + 5*x^3"); commit 949508429ea9850b8ec36d862f4e4d291773c313 Author: Alexei Sheplyakov Date: Sat Sep 13 04:21:27 2008 +0400 [BUGFIX] parser.hpp: fix include guard so the header is actually usable. commit 4cbc8e8bdf06fd91ec652e9645965a5f1a808d76 Author: Alexei Sheplyakov Date: Fri Sep 12 19:55:36 2008 +0400 [nitpick] power::expand_add(): don't use int instead of std::size_t. This shuts a few 'comparison between signed and unsigned integer expressions' warnings. commit 1f7f3c85ec1b8063f475789544e9392ce59beb40 Author: Alexei Sheplyakov Date: Fri Sep 12 19:55:36 2008 +0400 [nitpick] inifcns_nstdsums: don't use int instead of std::size_t. This shuts up quite a number of 'comparison between signed and unsigned integer expressions' warnings. commit bd3ecf75ed2a77b9f56fc31f7923fc0f4d1982d4 Author: Alexei Sheplyakov Date: Fri Sep 12 19:55:36 2008 +0400 [nitpick] don't use int instead of std::size_t. This shuts up (some of) 'comparison between signed and unsigned integer expressions' warnings. commit 5d367f84b43b0636f943fe239f7a58b4d147f002 Author: Alexei Sheplyakov Date: Thu Sep 11 15:16:21 2008 +0400 G_numeric: use cl_N and int to manipulate numbers (instead of ex). Convert helper functions G_do_hoelder and G_do_trafo in the same manner, update all call sites. This should speed up numerical calculation of multiple polylogarithms a little bit, and reduce the memory usage. commit 502e76319b484c32246707e33e70a428ac5dc6ad Author: Alexei Sheplyakov Date: Wed Sep 10 15:43:35 2008 +0400 G_numeric: put convergence/acceleration transofrmations into helper functions. This is simple code move, everything else should be considered a bug. The helper functions (as well as G_numeric itself) will be improved by subsequent patches. commit 4f596b14ac1cdb03163c74e210cab493358ababf Author: Alexei Sheplyakov Date: Fri Sep 12 14:55:42 2008 +0400 match() (find()): use exmap (exset) to store matched subexpressions. There's no need to re-invent associative arrays and wrap them into a GiNaC class. commit 3918e4767063fb45e5728bd9b3a09dd8ac30d055 Author: Alexei Sheplyakov Date: Thu Sep 11 16:59:30 2008 +0400 expairseq::match(): remove the code which works around basic::match bug. basic::match() used to have side effects in a case of a failed match. As a result of that bug exparsed::match did not work correctly in some cases, see [1] for more details. These false negatives were worked around by [2]. Now that match() has no unwanted side effects [3] we don't need any work arounds any more. Just in a case add a regression test (from [1]). [1] http://www.ginac.de/pipermail/ginac-devel/2006-April/000942.html [2] Commit 73f0ce4cf8d91f073f35a45443f5fbe886921c5c ("Fixed bugs in ::match"). [3] Commit 192ed7390b7b2b705ad100e3db0a92eedd2b20ad ("match: don't modify subexpression list if expression doesn't match the pattern."). commit 4ee761760b3db8649b8b616256cd7466fe2cd033 Author: Jens Vollinga Date: Thu Sep 18 20:26:37 2008 +0200 Fixed various bugs in multivariate factorization. commit b8150271ff497c2ef0c2a8748f5f53b4f1bab7c8 Merge: 7d23da3e0ee0d03f90f47585ea27f86ecbfe866b c647bf0942d660691272a8a2f4d7e5a3c0f6eb0f Author: Jens Vollinga Date: Tue Sep 9 22:42:50 2008 +0200 Merge branch 'master' of git://ffmssmsc.jinr.ru:443/varg/ginac commit 7d23da3e0ee0d03f90f47585ea27f86ecbfe866b Author: Jens Vollinga Date: Tue Sep 9 22:41:39 2008 +0200 Bug fix related to the usage of int instead of cl_I. commit 416f530b032f2861bb3cb96d23f14097237a87ea Author: Jens Vollinga Date: Tue Sep 9 22:41:24 2008 +0200 Updated NEWS. commit c647bf0942d660691272a8a2f4d7e5a3c0f6eb0f Author: Alexei Sheplyakov Date: Tue Sep 9 14:44:25 2008 +0400 build: shut up automake warnings, don't use GNU make extensions. Not that I really care about non-GNU makes, but those warnings are a bit annoying and can hide useful ones. commit 93eb93a10a2f29360baa4ab45d5b34b982c7fa5c Author: Alexei Sheplyakov Date: Mon Sep 8 11:53:30 2008 +0400 build: put (almost) all auto* tools scripts into the config directory. So I can just rm -rf it to clean up the repository. commit a32a30d8ccdd0eb945b8180c8fe82d154e9280de Author: Alexei Sheplyakov Date: Mon Sep 8 11:09:20 2008 +0400 Allow user to disable GiNaC::compile_ex (e.g. for security reasons). configure takes --{disable,enable}-excompiler argument now. It can be used to disable GiNaC::compile_ex (default is to enable it). acinclude.m4: GINAC_EXCOMPILER: new macro. Checks for libdl, allows user to disable GiNaC::compile_ex. Also it doesn't bother to check for libdl on MinGW. configure.ac: use GINAC_EXCOMPILER to check for libdl. commit e677a783b3c986ceb873a580a18f2214ad6de52c Author: Alexei Sheplyakov Date: Sun Sep 7 22:53:07 2008 +0400 configure: run important checks first (and bail out if something is missing). Don't bother to check for optional stuff if CLN and/or standard C++ headers are missing. commit a3009dfc5402f6253e9219201f48d972dd46984b Author: Alexei Sheplyakov Date: Sun Sep 7 22:47:01 2008 +0400 configure: don't bother to run checks which can be done at the compile time. Don't check for sizeof of various types, this can be done at the compile time. GCC optimizes away these checks, so the actual code is the same. commit 4a9f6c276daf54acbb2f5951f0435bfb6f014809 Author: Alexei Sheplyakov Date: Sun Sep 7 22:17:55 2008 +0400 utils.h: use (if available) instead of reinventing it. The argument of golden_ratio_hash() is as an integer of the same size as a void* pointer. Unfortunately ISO C++ 98 does not provide suitable typedef. Hence * use if available and define p_int to uintptr_t. Note: AC_PROG_CC already checks for this header, so no extra checks are necessary. * as a fallback define p_int to be unsigned long, this works on most systems I know of (the only exception is woe64). While at it, stop including "config.h" unconditionally. commit b21923803208edf7ec3b0bfaa51f813cb25a0d86 Author: Alexei Sheplyakov Date: Sat Sep 6 09:21:18 2008 +0400 configure: don't check for sizeof(long double), we don't use it. commit 66633e0aca7656c2826e2fd06dc638eac8900660 Author: Alexei Sheplyakov Date: Sat Sep 6 08:51:19 2008 +0400 build: faster check for standard C++ headers. Include them all into a test program and check if it compiles (in order to reduce the run time of the `configure' script). commit 0f26d08929532724d24a60e9fa5e5e98c4b2fa55 Author: Alexei Sheplyakov Date: Mon Jun 9 16:21:30 2008 +0400 build: don't run any ${host} binaries while checking for readline. Now GiNaC (to be more precise, ginsh) can be easily cross compiled. However, ancient versions of readline (<= 4.2) are not supported any more. commit db751462877f91d8b76a0fd80d48330eddcb7095 Author: Alexei Sheplyakov Date: Mon Sep 8 11:50:12 2008 +0400 don't mention CVS any more, describe how to install from git. commit 192ed7390b7b2b705ad100e3db0a92eedd2b20ad Author: Alexei Sheplyakov Date: Tue Jul 15 21:08:22 2008 +0400 match: don't modify subexpression list if expression doesn't match the pattern. As of now the match() method modifies the list of matched subexpressions (its second argument) even if the expression in question does not match the pattern. Thus, this simple program #include #include using namespace GiNaC; int main(int argc, char** argv) { symbol x; ex e = pow(x, 5); ex pattern = pow(wild(), -1); lst repl; bool test = e.match(pattern, repl); std::cout << "repl = " << repl << std::endl; } prints repl = {x} Such behaviour is a bit unexpected. Sometimes it confuses even GiNaC developers, see e.g. http://www.ginac.de/pipermail/ginac-devel/2006-April/000942.html Hence this patch. Now the above program prints repl = {} as expected. commit aff357309f6611a59efb10d06d3dcfd3812a9ec5 Author: Alexei Sheplyakov Date: Tue Aug 19 15:39:46 2008 +0400 [BUGFIX] Reclaiming the memory allocated for static objects *is* necessary. GiNaC allocates memory for static objects (i.e. flyweights, remember tables, etc), but doesn't free it. This is OK if the program lifetime matches libginac lifetime, since the OS will reclaim that memory anyway. However, if the program lifetime is different from that of libginac, this turns into a memory leak. This happens if someone dlopen's libginac.so, and dlclose's it later on (read: if someone uses GiNaC via scripting language bindings). symbol::autoname_prefix(): there's no need for dynamical memory allocation. remember_table::remember_tables(): likewise. function::registered_functions(): likewise. lib_init::~lib_init(): if library usage count drops to 0, reclaim the memory allocated for flyweights. commit 1776cd33da528c878ef1fb5530f8ac788e445ee5 Author: Alexei Sheplyakov Date: Tue Sep 9 11:14:57 2008 +0400 symbol: get rid of assign/unassign (for performance and other reasons). * symbol::eval() is trivial now, so compiler can inline it in some cases. * symbol takes less memory. * no functionality is lost (as C++ has associative arrays). commit eaa0370ac188561e02195a377b252b4caf5ab57a Author: Alexei Sheplyakov Date: Tue Sep 9 10:39:26 2008 +0400 ginsh: use exmap for storing assigned symbols. C++ already have associative arrays, there's no need to re-invent them. commit dae52def8dd15914d32c94c2c21e2bd8419b65bb Author: Alexei Sheplyakov Date: Fri Aug 29 23:44:51 2008 +0400 multiple zeta values: make crandall_Y_loop helper function reentrant. * Move crB and crG variables into initcX function (the only user of these variables). * Pass crX coefficients to crandall_Y_loop instead of using a global variable. * While at it make crandall_Y_loop and initcX functions static. commit 773570d668a8a86d4c646dfe9d8572746329652c Author: Alexei Sheplyakov Date: Fri Aug 29 23:44:51 2008 +0400 multiple zeta values: make crandall_Z helper function reentrant. Pass the f_kj coefficients as an arguments to crandall_Z and calc_f functions instead of using global variables. commit 85dbe3f2049dce7d43a1bd956d622f4ff5c0c156 Author: Alexei Sheplyakov Date: Mon Aug 25 19:08:36 2008 +0400 parser: improve error reporting a little bit. Introduce class 'parse_error' (which contain some info about location of the error) and throw it on parse errors. N.B.: the actual info is a bit inaccurate because lexer doesn't track the location properly yet. commit 581244b7b8fc9b5f81291e1a3f5731939e3f3d8e Author: Alexei Sheplyakov Date: Mon Aug 25 17:49:58 2008 +0400 lexer: when switching to another output stream, clean last read character. Otherwise we prepend to the current stream the last character read from the previous stream, which is obviously incorrect. commit bb6b3d82cdf9e7ff4ecac89c47e63024e39ec96b Author: Jens Vollinga Date: Mon Sep 8 19:17:56 2008 +0200 Fixed bug in unvariate factorization. Bound for lifting was using a ordinary int instead of a cl_I. commit ccec535ede5a414447d69fba95af194df7327bfb Author: Jens Vollinga Date: Mon Sep 8 18:32:27 2008 +0200 Added missing code for multivariate factorization. commit dacdde924c6d2e43ec52c2d6310d208d8e4024f6 Author: Jens Vollinga Date: Mon Sep 8 18:17:51 2008 +0200 Fixed bug. G() ignored the imaginary parts of the arguments. commit 55af76071727bd6e2fd540ad58eac26dd961f9c9 Author: Jens Vollinga Date: Wed Aug 27 17:25:16 2008 +0200 Added internal code for multivariate factorization. commit a79a813e7249f793859d1d3b443d1931dbab94b6 Author: Alexei Sheplyakov Date: Mon Aug 25 16:57:38 2008 +0400 gcd_pf_pow_pow: deobfuscate a little bit (no functional changes). Use if (foo) return bar(); return baz(); instead of if (foo) { return bar(); } else { return baz(); } This makes the code a little bit more readable. commit 6ff92476a4dcd32f9a0c6f59c95c74812ea86fef Author: Alexei Sheplyakov Date: Mon Aug 25 16:57:02 2008 +0400 gcd_pf_pow: get rid of duplicate code. This function (which helps gcd() handle partially factored expressions) contained two copies of the same code. Remove one redundant copy. commit 55e50ea26252dff7432bdce8b010f9fbd058e907 Author: Alexei Sheplyakov Date: Mon Aug 25 16:56:04 2008 +0400 introduce gcd_pf_pow_pow: gcd helper to handle partially factored expressions. gcd_pf_pow_pow handles the case when both arguments of gcd() are powers. N.B. the actual code moved from gcd_pf_pow, no functional changes. commit 1d09676118944532e6100c93383d1659b1253a60 Author: Alexei Sheplyakov Date: Mon Aug 25 16:55:42 2008 +0400 gcd_pf_{pow, mul}: don't check if the arguments are polynomials. These functions gets called only from gcd(), which does this check on its own. commit adb1dbd383ae6e5a999b5f8cba72a5c2bfd50c11 Author: Alexei Sheplyakov Date: Mon Aug 25 16:55:13 2008 +0400 gcd_pf_mul: get rid of duplicate code. This function (which helps gcd() handle partially factored expressions) contained two copies of the same code. Remove one redundant copy. commit c77689e7ac8d8f4dbca0f337b6e9acf2419010ff Author: Alexei Sheplyakov Date: Mon Aug 25 16:54:46 2008 +0400 gcd(): allow user to override (some of) heuristics. GiNaC tries to avoid expanding expressions while computing GCDs and applies a number of heuristics. Usually this improves performance, but in some cases it doesn't. Allow user to switch off heuristics. Part 5: * gcd(): don't use heuristic GCD algorithm if gcd_options::no_heur_gcd flag is set. * gcd(): don't handle partially factored expressions in a special way if gcd_options::no_part_factored flag is set. commit 77b6a0304a48d6a306deeda18177680f16025b33 Author: Alexei Sheplyakov Date: Mon Aug 25 16:54:10 2008 +0400 refactor gcd() a little bit (no functional changes). GiNaC tries to avoid expanding expressions while computing GCDs and applies a number of heuristics. Usually this improves performance, but in some cases it doesn't. Allow user to switch off heuristics. Part 4: refactor gcd() a little bit, so subsequent patch(es) won't be so big and ugly. commit 7d7131d3af3de5425b7fe80b1f587740294371bc Author: Alexei Sheplyakov Date: Mon Aug 25 16:53:47 2008 +0400 introduce gcd_pf_mul: gcd helper to handle partially factored expressions. GiNaC tries to avoid expanding expressions while computing GCDs and applies a number of heuristics. Usually this improves performance, but in some cases it doesn't. Allow user to switch off heuristics. Part 3: Move the code handling products from gcd() into a separate function. This is *really* only code move, everything else should be considered a bug. commit b65fcd7481a401ec23c284c91f6f4e883e967676 Author: Alexei Sheplyakov Date: Mon Aug 25 16:53:07 2008 +0400 introduce gcd_pf_pow: gcd helper to handle partially factored expressions. GiNaC tries to avoid expanding expressions while computing GCDs and applies a number of heuristics. Usually this improves performance, but in some cases it doesn't. Allow user to switch off heuristics. Part 2: Move the code handling powers from gcd() into a separate function. This is *really* only code move, everything else should be considered a bug. commit 8474043d373a19e04008f476fa9b77e45734b604 Author: Alexei Sheplyakov Date: Mon Aug 25 16:52:45 2008 +0400 gcd: allow user to override (some of) heuristics. GiNaC tries to avoid expanding expressions while computing GCDs and applies a number of heuristics. Usually this improves performance, but in some cases it doesn't. Allow user to switch off heuristics. Part 1: * add new (optional) argument to gcd() to control its behaviour. * introduce gcd_options structure. N.B. No actual code changes so far, the actual handling of newly introduced options is the subject of further patches. commit ff09c4f8103f53fe3b7a51eb3c33eff2e5a243f0 Author: Alexei Sheplyakov Date: Sun Aug 24 15:25:24 2008 +0400 inifscn_nstdsums: make functions handling Li/G transformations reentrant. Explicitly pass the dummy symbols instead of using a global variable. As a side effect, the code is more clear now (that's a bit subjective, but anyway). commit b4b302fe5d54720b58a23568a4270e04ee1ca216 Author: Alexei Sheplyakov Date: Fri Aug 22 02:42:17 2008 +0400 Bail out if both autogen and autogen'erated file(s) are missing. This makes the error message(s) more helpful. commit 1222eac51cee964961d2aad889dc4ceccb144a36 Author: Alexei Sheplyakov Date: Tue Aug 19 23:48:03 2008 +0400 Faster, better (recursive descent) expression parser. Ouch, it fails to compile. Here is a correct version: From: Alexei Sheplyakov Date: Tue, 19 Aug 2008 21:50:03 +0400 Subject: [PATCH] Faster, better (recursive descent) expression parser. bison generated parser has a number of problems: 1. Bad performance. Parsing a sum seems to be O(N^{2 + a}) (a > 0) [1]. For example, parsing a sum (actually, a univariate polynomial) of 32768 terms takes about 90 sec. on my box, parsing a sum of 10^6 terms takes "eternity". 2. The user is expected to provide list of all symbols in the expression. Often this is very annoying (and useless). 3. Parser is not reentrant (bison *can* produce reentrant parsers, but that won't solve other problems). 4. Parser is difficult to extend. Hence the new parser. Features: 1. Parsing large sums and products is O(N). 2. Parser is reentrant (well, almost). 3. It's possible to insert (shell style) comments inside the expressions. 4. matrices, lists, FAIL are NOT handled. Yes, this *is* a feature :-) Limitations: 1. Error handling is a bit terse: on error exception is thrown, and that's it. 2. Binary, octal, and hexadecimal numbers can not be parsed (yet). 3. Tensors, noncommutative products, etc. can not be parsed. Other notes: 1. ex ctor still uses the old parser. 2. ginsh still uses the old parser. [1] Mesured by this script (requires gnuplot): make_expression_string () { printf "1 + x" local n=2 while test $n -le $1; do printf " + %s*x^%s" $n $n n=$(expr $n + 1) done } single_test () { printf "$1 \t" ( printf "time("; make_expression_string $1; printf ");" ) | \ ginsh | sed -e 's/s$//' } benchmark () { local N=$1 while test $N -le $2; do single_test $N N=$(expr $N \* 2) done } gnuplot_header () { echo "set logscale xy" echo "set xlabel 'degree (# of terms)'" echo "set ylabel 'time, sec.'" echo "set xrange [${1}:${2}]" echo "plot '-' using 1:2 with lines title '1+x+2*x^2+...+n*x^n'" } gnuplot_footer () { echo "e" } benchmark_and_plot () { ( gnuplot_header $1 $2 benchmark $1 $2 | tee $3.txt gnuplot_footer ) | \ gnuplot -persist '-' } N_ini=${1:-1024} N_fin=${2:-32768} out_base=${3:-parser_benchmark} benchmark_and_plot $N_ini $N_fin $out_base commit 321d5c941f81b1d0b86de91f3f17c5af5b6e4642 Author: Jens Vollinga Date: Thu Aug 21 22:37:09 2008 +0200 Daily bugfix in the polynomial factorization (code didn't catch polynomial "x" and cln::sqrt conversion was buggy). commit 37c418c602485be9b023378a1b60ebdb4a592f2a Author: Jens Vollinga Date: Wed Aug 20 22:16:13 2008 +0200 Fixed bug in the Q matrix calculation and the univariate factorization function. commit f3eefbda588318e09dcb3180c6f039dc3fc30f87 Author: Jens Vollinga Date: Mon Aug 18 21:10:48 2008 +0200 Fixed bug in modular square-free factorization. commit d08150300eb98c6435a4c464c057ba2967a19c8f Author: Jens Vollinga Date: Sat Aug 9 10:14:02 2008 +0200 Added polynomial factorization (univariate case). commit 114449ae6f2cd3151d9b8342c570db021a9e892c Author: Jens Vollinga Date: Sat Aug 9 10:11:40 2008 +0200 Added polynomial factorization (univariate case). commit 5e9875d5f67a68d2cb680454ff4de480bad1b6f1 Author: Alexei Sheplyakov Date: Wed Jul 30 20:32:46 2008 +0400 Any complex number can be (un)archived properly. A complex number can have an exact real part and inexact (floating point) imaginary part, and vice a versa. Handle these cases properly in the archiving code instead of bailing out with a bizzare error message. Thanks to Chris Bouchard for reporting the bug. NOTE: this fix changes the format of GiNaC archives, so formally it breaks the binary compatibility. However, "mixed" complex numbers (i.e. ones with exact real part and inexact imaginary part) can not be archived with previous versions of GiNaC, so there's nothing to break. commit a7693a0f710b49494f95ce5a4a0953752e69c7f9 Author: Alexei Sheplyakov Date: Wed Mar 19 12:28:34 2008 +0300 define lgamma and tgamma taking cl_N as an argument. The actual code is the same. These functions are OK since cl_N is not automatically converted to numeric any more. commit 2d52c00438cde2c47f43620d26d78022f0d60746 Author: Alexei Sheplyakov Date: Wed Mar 19 12:28:10 2008 +0300 Implicit conversion from cl_N to numeric considered harmful. Finally, mark the numeric(const cl_N&) ctor as explicit. This allows one to mix the code using GiNaC and CLN, i.e. cl_N x, y; // initialize them cl_N z = sin(x) + y*exp(y); symbol a("a"); ex e = exp(a); commit a297391b22c1a4ec3464d13191f8cb33332c9863 Author: Alexei Sheplyakov Date: Wed Mar 19 12:27:27 2008 +0300 bernoulli, fibonacci, iquo: explicitly convert return values to numeric. Implicit conversion from cl_N to numeric considered harmful, part 6. commit 5ea14a22768031a1cd4abce2926d5359c5d0c15f Author: Alexei Sheplyakov Date: Wed Mar 19 12:27:07 2008 +0300 tgamma, lgamma: convert to take cl_N as an argument; provide wrappers for GiNaC::numeric Implicit conversion from cl_N to numeric considered harmful, part 5. commit 7bc327c75aaa3118de14dfcee59bcf0fd40e3f4a Author: Alexei Sheplyakov Date: Wed Mar 19 12:26:52 2008 +0300 Li2, zeta, sqrt, abs, gcd, etc.: explicitly convert return value to numeric. Implicit conversion from cl_N to numeric considered harmful, part 4. commit 58aaaf83c55c5784e1d94c2a794af96d7769165b Author: Alexei Sheplyakov Date: Wed Mar 19 12:26:23 2008 +0300 elementary functions: explicitly convert return values from cl_N to numeric. Implicit conversion from cl_N to numeric considered harmful, part 3. commit 6335b2cfb6f3f9ec339ff683bed415a5879d7909 Author: Alexei Sheplyakov Date: Wed Mar 19 12:25:55 2008 +0300 inifcns_nstdsums.cpp: Lin_numeric takes cl_N as an argument instead of numeric. Implicit conversion from cl_N to numeric considered harmful, part 2. commit 2406529f5ceb193a46b1b5a07a8810880a8ceceb Author: Alexei Sheplyakov Date: Wed Mar 19 12:24:36 2008 +0300 inifcns_nstdsums.cpp: S_num takes cl_N as an argument instead of numeric. Implicit conversion from cl_N to numeric considered harmful. Using GiNaC::numeric for numerical computations incurs significant overhead, so one might want to do these computations using proper CLN types. Unfortunately, it's not easy due to automatic conversion from cln::cl_N to GiNaC::numeric. Here is a simple example: cl_N x, y; // initialize them return sin(x) + y*exp(y); The compiler complains about ambigously overloaded of functions, i.e. cl_N cln::sin(const cl_N&) versus numeric GiNaC::sin(const numeric&). Hence, I propose to disable *implicit* conversion from cl_N to numeric (this can be done by marking the numeric ctor as `explicit'). However, this change happens to be a bit nontrivial, because that evil conversion is used in GiNaC itself. So, I decided to rewrite those fragments of code. commit e20fd5e760136cf343f4d2d73d0f3dfc6573ac49 Author: Richard B. Kreckel Date: Tue Jul 15 23:57:43 2008 +0200 documentation: it is get_dim(), not get_dimension() This was misdocumented ever since GiNaC-0.8.0. commit cb078dba2a491d80a34924b29bd8d3992c18b7fe Author: Alexei Sheplyakov Date: Mon Jul 14 17:46:25 2008 +0400 clifford_unit: fix possible bugs due to wrong operator[!=]= usage. commit 37d324b137fcb61384203b711e91d8919535f237 Author: Jens Vollinga Date: Wed Jun 25 11:28:11 2008 +0200 Removed left-over debugging line. commit 26c31eb89fe38c4d232f90b62c8acbeaaa0454f4 Author: Jens Vollinga Date: Wed Jun 25 11:17:55 2008 +0200 Make the behaviour of class function more consistent with respect to ncmul::eval(). [V.Kisil] commit fd4fbeaa409cd807e4f2f7501d278e835e964d69 Author: Jens Vollinga Date: Tue Jun 24 21:26:58 2008 +0200 Improve heur_gcd() so it can handle rational polynomials, and add a test case. Previously heur_gcd() worked only with integer polynomials, and did not check if the inputs are indeed integer polynomials. That lead to an endless loop or a miscomputed gcd. [A.Sheplyakov] commit 6850c16435de33396ccd505ff26b4d4574fa74cf Author: Jens Vollinga Date: Fri Apr 4 14:48:19 2008 +0200 Fixed bug in mLi summation causing premature drop-out and made Nielsen polylog invalidate its lookup tables if precision has been changed. commit f152bcaada41397cdf12d21fc2c4172d77ab7cb2 Author: Jens Vollinga Date: Fri Apr 4 14:47:07 2008 +0200 Added legacy tests for zeta and multiple polylog. commit 1254f5ef941aa6ead793e843b637edc927f47c7d Author: Jens Vollinga Date: Wed Dec 13 20:04:23 2006 +0000 Check for fixed bug in multiple polylogs. commit fb45203612dcfd2e30f6e7a43273597bcd13f026 Author: Jens Vollinga Date: Thu Apr 3 11:56:57 2008 +0200 Fixed bugs found by Jianqiang Zhao. commit 3c85fea898265651ad22baa22aa002a819e5c536 Author: Richard B. Kreckel Date: Thu Mar 27 23:56:32 2008 +0100 Adjust for GiNaC 1.5. commit 83a7ee99a947cbbf331018b803ad6be43a9ccd45 Merge: 4549628b93b6a795baf8f2dc836838acb88b4ffa 56a180a49e085b325c0e6e49a2e2db07c570ef7b Author: Jens Vollinga Date: Thu Mar 27 11:16:11 2008 +0100 Merge commit 'origin/master' commit 4549628b93b6a795baf8f2dc836838acb88b4ffa Author: Jens Vollinga Date: Thu Mar 27 11:08:09 2008 +0100 Fixed make distcheck issues. commit 56a180a49e085b325c0e6e49a2e2db07c570ef7b Author: Richard B. Kreckel Date: Thu Mar 27 00:50:19 2008 +0100 Update debian/changelog in anticipation of release. In reality, I'm testing the post-receive hook. commit 67467d256b44f5e08498ca81c946d9ffaa25d1e2 Merge: da211dc876958abc2563de16aff673296053505e 3bcd3124f2ebfec57e84c59a6b380b0681776072 Author: Richard B. Kreckel Date: Thu Mar 27 00:05:38 2008 +0100 Merge git://www.ginac.de/ginac commit 3bcd3124f2ebfec57e84c59a6b380b0681776072 Author: Jens Vollinga Date: Wed Mar 26 13:33:55 2008 +0100 Small improvement to VPATH fix. commit dbc0d24eb31cb6229e172b062fd102990fb3062a Author: Jens Vollinga Date: Wed Mar 26 13:09:00 2008 +0100 Fixed info-generation problems with VPATH builds. commit da211dc876958abc2563de16aff673296053505e Author: Richard B. Kreckel Date: Wed Mar 26 00:03:08 2008 +0100 Update debian/ files. Use the files that were uploaded with GiNaC 1.4.1 in Debian. commit 7d870583a6bf21a2ffb7b6f051b702064623892e Author: Richard B. Kreckel Date: Tue Mar 25 22:59:52 2008 +0100 Happy new year! Updated all copyright notices. commit d7c5ca75b0fc9e58a8676681e3801869e47ad911 Author: Alexei Sheplyakov Date: Tue Mar 18 09:45:25 2008 +0300 move rotate_left() function away from the public header. commit 090348bcd9ac2104e1e387430aecd5c8b7289633 Author: Alexei Sheplyakov Date: Tue Mar 18 09:24:56 2008 +0300 INSTALL: libreadline is not mandatory; ginsh builds just fine without it. commit 433e73f28bef23bd1e3135613f91c283aca97c59 Author: Alexei Sheplyakov Date: Tue Mar 18 09:04:12 2008 +0300 update the compiler info; tell users to avoid GCC 4.3.0 commit 3cb110c5ca2330a0a155660f32d42e3d0ebc0db1 Author: Alexei Sheplyakov Date: Tue Mar 4 12:46:59 2008 +0300 symbol.cpp: shut up useless warnings ../../sw/ginac/ginac/symbol.h: In constructor 'GiNaC::symbol::symbol()': ../../sw/ginac/ginac/symbol.h:112: warning: 'GiNaC::symbol::ret_type_tinfo' will be initialized after ../../sw/ginac/ginac/symbol.h:110: warning: 'unsigned int GiNaC::symbol::domain' ../../sw/ginac/ginac/symbol.cpp:47: warning: when initialized here ../../sw/ginac/ginac/symbol.h: In constructor 'GiNaC::symbol::symbol(const std::string&, unsigned int)': ../../sw/ginac/ginac/symbol.h:112: warning: 'GiNaC::symbol::ret_type_tinfo' will be initialized after ../../sw/ginac/ginac/symbol.h:110: warning: 'unsigned int GiNaC::symbol::domain' ../../sw/ginac/ginac/symbol.cpp:75: warning: when initialized here ../../sw/ginac/ginac/symbol.h: In constructor 'GiNaC::symbol::symbol(const std::string&, unsigned int, const void*, unsigned int)': The warnings are a bit silly, but they can hide more useful ones. commit c3c748381bda4f81b68e50db2eed440c19f24b85 Author: Alexei Sheplyakov Date: Thu Feb 28 10:11:50 2008 +0300 check: indicate the test failures with non-zero exit code; split test programs. IMNSHO parsing the output of test programs in order to check if the tests passed is a bad idea (and it causes *real* problems, see e.g. http://www.ginac.de/pipermail/ginac-list/2008-February/001345.html). It's much simpler and cleaner to indicate the failure in a genuine *NIX way: exit with nonzero code. commit 3a56e58f6a3e2dac83f12c254d0d7549bb886af4 Author: Richard Kreckel Date: Sat Feb 23 02:27:56 2008 +0000 * Version 1.5. commit f69a24a4fd6caf42ef773d1cef21562a8afa068a Author: Richard Kreckel Date: Fri Feb 22 04:23:57 2008 +0000 * Improved lsolve() of systems containing non-numeric coefficients. commit 3c3275884e65193743d4b2bcd98637949791aef8 Author: Alexei Sheplyakov Date: Fri Dec 28 17:51:16 2007 +0300 kill spurious comma in flags.h commit 37678db7297076f166969b92d5d96f1d46b7fdee Author: Alexei Sheplyakov Date: Sat Dec 15 00:07:04 2007 +0300 check/*_memleak.cpp: fix botched CVS commit[s]. commit eb207d1c42ae5aed9ed6d9695a4ff44f62d72540 Author: Alexei Sheplyakov Date: Fri Dec 14 17:31:06 2007 +0300 Improve instructions for installing GiNaC from CVS. * prerequisites: mention libtool, flex, and bison. * installation: required software should be installed BEFORE generating the `configure' script. commit 2ba3a7625b322bdd07dfae38a9a3843ac1df1461 Author: Richard Kreckel Date: Wed Dec 12 04:57:03 2007 +0000 * Fix GCC 4.3 compilation issue by removing storage class of function coerce specializations [C++98 7.1.1-1]. commit 789b6b908fadc1139e9bc1a4611cc957ad11579b Author: Jens Vollinga Date: Thu Nov 22 02:40:31 2007 +0000 Fixed memory leak program. commit 48a6c5094dd4ff641d0875b1303cfa8b2b489da1 Author: Jens Vollinga Date: Wed Nov 21 04:37:53 2007 +0000 * Fixed module loading bug (occured if . was not in the library path). commit e9ae06f2ddceabb66ff93bacc059d6fa0348beee Author: Jens Vollinga Date: Wed Nov 21 04:28:26 2007 +0000 * Fixed broken preprocessor instruction [Sheplyakov]. commit f164fa76f440bf7a455ca65abaf0f031f715f076 Author: Jens Vollinga Date: Wed Nov 21 04:20:44 2007 +0000 * Fixed memory leak in ginac_yylex() [Sheplyakov]. commit 86fe62b1f98e61167e0f1012ff078a2f1547458f Author: Jens Vollinga Date: Wed Nov 21 04:19:50 2007 +0000 Added small program that exhibits the memory leak in the ginac_yylex() [Sheplyakov]. commit e8b25d30502c630a181b1fa95f11b15a94a2bc74 Author: Jens Vollinga Date: Wed Nov 21 04:14:32 2007 +0000 * Deleted bogus try -- catch block in the ex::series() [Sheplyakov]. commit 0ad11afda76f83eb74b5868af6efd550bdfe52a1 Author: Jens Vollinga Date: Wed Nov 21 04:13:13 2007 +0000 * Added check for memory leak in {mul,power}::eval [Sheplyakov]. commit 7579c2252464254878cb301d409991527356d23e Author: Jens Vollinga Date: Wed Nov 21 04:01:20 2007 +0000 * Fixed macro checking for version of libreadline (Mac OS X) [Sheplyakov]. commit 39ad156482436e2c6e9cb3424520d80dab09180c Author: Richard Kreckel Date: Tue Oct 16 06:19:15 2007 +0000 * Fix optimization opportunities missed by Alexei's patch. commit 2ae785e9cfce5067d4092ca6b5b92d2799867ca9 Author: Jens Vollinga Date: Mon Oct 15 23:41:21 2007 +0000 - Do not bother to rename indices if object has no indices at all [Sheplyakov]. commit a58e540b7d534d64c1c87cc253b3cf40bf58df06 Author: Jens Vollinga Date: Mon Oct 15 23:40:57 2007 +0000 - This helps mul::expand() and friends to recognize objects which have no indices at all [Sheplyakov]. commit da6a61ba2586263e46ade4b67dca121506c2bff9 Author: Jens Vollinga Date: Mon Oct 15 23:40:30 2007 +0000 - Apparently, in ~ 30% of calls to mul::expand the expression is monomial. Expanding monomials should be done as fast as possible [Sheplyakov]. commit 7d05f39c095dc51cc4526b17a5ab3280f8924219 Author: Jens Vollinga Date: Mon Oct 15 23:39:42 2007 +0000 - Partially solves performance regression in expand(), gcd(), etc [Sheplyakov]. commit 9fe3a96b35a68c4f6c16c21322161dbb26118ed0 Author: Jens Vollinga Date: Mon Oct 15 23:39:01 2007 +0000 - info(info_flags::has_indices) now works for sums and products. It returns true if the expression has indices (no matter dummy or free), and false otherwise [Sheplyakov]. commit a5196f57af6539d8a25a866ad9cf8d836dd8e3df Author: Jens Vollinga Date: Fri Sep 7 18:48:22 2007 +0000 Improved CLN output [Sheplyakov]. commit 886ff58c2675aee6bd37469ce966924b40cc448d Author: Jens Vollinga Date: Wed Sep 5 16:52:25 2007 +0000 Added example for mystring class [Sheplyakov]. commit 85100a37f605d4c63fab87c3de4a7ba7bbbd041d Author: Jens Vollinga Date: Wed Sep 5 16:43:49 2007 +0000 Removed reference to autogen.sh [Sheplyakov] commit 4c23357ed68847190271224adf092fc37ff6e553 Author: Richard Kreckel Date: Wed Sep 5 05:25:12 2007 +0000 * Adjust to files used for rolling Debian's 1.4.0-1 GiNaC packages. commit eed9352ec69b68db0c5095376746ccf139c5d03a Author: Richard Kreckel Date: Wed Sep 5 04:42:37 2007 +0000 Put entire GiNaC documentation into @dircategory 'Mathematics' for info. ----------------------------------------------------------------------- hooks/post-receive -- GiNaC -- a C++ library for symbolic computations From varg at metalica.kh.ua Mon Feb 23 13:03:16 2009 From: varg at metalica.kh.ua (Alexei Sheplyakov) Date: Mon, 23 Feb 2009 14:03:16 +0200 Subject: [GiNaC-devel] [PATCH] Fix compilation failure due to (template) operator- defined in factor.cpp Message-ID: <20090223120316.GA31092@metalica.kh.ua> GiNaC 1.5.0 fails to compile with g++ 3.4: /bin/bash ../libtool --tag=CXX --mode=compile ccache g++-3.4 -DHAVE_CONFIG_H -I. -I../../../../work/sw/GiNaC/ginac -I../config -I/home/pc7135/varg/target/x86_64-linux-gnu/include -Wall -O2 -g -pipe -funroll-loops -ffast-math -finline-limit=1200 -m64 -march=k8 -mfpmath=sse -msse2 -MT factor.lo -MD -MP -MF .deps/factor.Tpo -c -o factor.lo ../../../../work/sw/GiNaC/ginac/factor.cpp libtool: compile: ccache g++-3.4 -DHAVE_CONFIG_H -I. -I../../../../work/sw/GiNaC/ginac -I../config -I/home/pc7135/varg/target/x86_64-linux-gnu/include -Wall -O2 -g -pipe -funroll-loops -ffast-math -finline-limit=1200 -m64 -march=k8 -mfpmath=sse -msse2 -MT factor.lo -MD -MP -MF .deps/factor.Tpo -c ../../../../work/sw/GiNaC/ginac/factor.cpp -fPIC -DPIC -o .libs/factor.o ../../../../work/sw/GiNaC/ginac/factor.cpp: In function `unsigned int GiNaC::unnamed::next_prime(unsigned int)': ../../../../work/sw/GiNaC/ginac/factor.cpp:1330: warning: converting of negative value `-0x00000000000000001' to `size_t' stl_vector.h: In member function `size_t vector::size() const': stl_vector.h:375: error: ambiguous overload for 'operator-' in '((const vector *)this)->vector::end() - ((const vector *)this)->vector::begin()' stl_iterator.h:759: note: candidates are: typename const_iter::difference_type operator-(const const_iter &, const const_iter &) ../../../../work/sw/GiNaC/ginac/factor.cpp:254: note: const_iter GiNaC::unnamed::operator-(const const_iter &, const const_iter &) stl_deque.h:825: error: ambiguous overload for 'operator-' in '((const _Deque_base *)((const deque *)this))->_Deque_base::_M_impl._Deque_base::_Deque_impl::_M_finish - ((const _Deque_base *)((const deque *)this))->_Deque_base::_M_impl._Deque_base::_Deque_impl::_M_start' stl_deque.h: In member function `size_t deque::size() const': ../../../../work/sw/GiNaC/ginac/factor.cpp:1534: instantiated from here stl_deque.h:671: instantiated from `deque::deque(const deque &)' ../../../../work/sw/GiNaC/ginac/factor.cpp:1534: instantiated from here ../../../../work/sw/GiNaC/ginac/factor.cpp:254: note: iter GiNaC::unnamed::operator-(const iter &, const iter &) ../../../../work/sw/GiNaC/ginac/container.h:375: error: ambiguous overload for 'operator-' in 'last - first' ../../../../work/sw/GiNaC/ginac/container.h: In member function `void GiNaC::container< >::read_archive(const GiNaC::archive_node &, GiNaC::lst &)': ../../../../work/sw/GiNaC/ginac/factor.cpp:2586: instantiated from here ../../../../work/sw/GiNaC/ginac/factor.cpp:2586: instantiated from here stl_iterator.h:759: note: typename const_iter::difference_type operator-(const const_iter &, const const_iter &) ../../../../work/sw/GiNaC/ginac/container.h:375: error: ambiguous overload for 'operator-' in 'last - first' ../../../../work/sw/GiNaC/ginac/container.h: In member function `void GiNaC::container< >::read_archive(const GiNaC::archive_node &, GiNaC::lst &)': ../../../../work/sw/GiNaC/ginac/factor.cpp:2586: instantiated from here ../../../../work/sw/GiNaC/ginac/factor.cpp:2586: instantiated from here stl_iterator.h:759: note: typename const_iter::difference_type operator-(const const_iter &, const const_iter &) The following (silly) code makes the problem easier to analyze: namespace N1 { template struct A { T1 val; typedef T2 diff_t; explicit A(const T1& t) : val(t) { } }; template typename T::diff_t operator-(const T& x, const T& y) { typedef typename T::diff_t diff_t; return diff_t(x.val - y.val); } } // namespace N1 namespace N2 { template T operator-(const T& x, const T& y) { return T(x.val - y.val); } int f() { ::N1::A a(1), b(1); return (a - b).val; // ill-formed: both // N1::A N2::operator-(const N1::A&, const N1::A&) // and // N1::A::diff_t N1::operator-(const N1::A&, const N1::A&) // match. } } // namespace N2 The fix is simple: declare (and define) operator- (and operator+) only for (univariate) polynomials. --- ginac/factor.cpp | 32 ++++++++++++++++++++++++++++++-- 1 files changed, 30 insertions(+), 2 deletions(-) diff --git a/ginac/factor.cpp b/ginac/factor.cpp index b8a1fb8..2f9157b 100644 --- a/ginac/factor.cpp +++ b/ginac/factor.cpp @@ -218,8 +218,32 @@ static void expt_pos(umodpoly& a, unsigned int q) } } +template struct enable_if +{ + typedef T type; +}; + +template struct enable_if { /* empty */ }; + +template struct uvar_poly_p +{ + static const bool value = false; +}; + +template<> struct uvar_poly_p +{ + static const bool value = true; +}; + +template<> struct uvar_poly_p +{ + static const bool value = true; +}; + template -static T operator+(const T& a, const T& b) +// Don't define this for anything but univariate polynomials. +static typename enable_if::value, T>::type +operator+(const T& a, const T& b) { int sa = a.size(); int sb = b.size(); @@ -250,7 +274,11 @@ static T operator+(const T& a, const T& b) } template -static T operator-(const T& a, const T& b) +// Don't define this for anything but univariate polynomials. Otherwise +// overload resolution might fail (this actually happens when compiling +// GiNaC with g++ 3.4). +static typename enable_if::value, T>::type +operator-(const T& a, const T& b) { int sa = a.size(); int sb = b.size(); -- 1.5.6.5 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 835 bytes Desc: Digital signature URL: From varg at metalica.kh.ua Mon Feb 23 13:08:42 2009 From: varg at metalica.kh.ua (Alexei Sheplyakov) Date: Mon, 23 Feb 2009 14:08:42 +0200 Subject: [GiNaC-devel] [PATCH] [woe32][bugfix] calchash(): work around broken RTTI. Message-ID: <20090223120842.GA31221@metalica.kh.ua> Due to the strange (although permitted by the standard) behaviour of C++ RTTI on woe32 calchash() returns different hash values for equal objects. As a result automatic evaluation gets spectacularly broken: examining clifford objects.....({1+t,2+x,3+y,4+z}) - ({1+t,2+x,3+y,4+z}) erroneously returned -{1+t,2+x,3+y,4+z}+{1+t,2+x,3+y,4+z} instead of 0 ({1+t,2+x,3+y,4+z}) - ({1+t,2+x,3+y,4+z}) erroneously returned -{1+t,2+x,3+y,4+z}+{1+t,2+x,3+y,4+z} instead of 0 .({1+t,2+x,3+y,4+z}) - ({1+t,2+x,3+y,4+z}) erroneously returned -{1+t,2+x,3+y,4+z}+{1+t,2+x,3+y,4+z} instead of 0 ({1+t,2+x,3+y,4+z}) - ({1+t,2+x,3+y,4+z}) erroneously returned {1+t,2+x,3+y,4+z}-{1+t,2+x,3+y,4+z} instead of 0 [skipped] .......FAIL: exam_clifford.exe This patch works around `features' of woe32 RTTI, so calchash() works properly. --- ginac/Makefile.am | 2 +- ginac/basic.cpp | 4 +- ginac/crc32.h | 74 ++++++++++++++++++++++++++++++++++++++++++++++++++ ginac/expairseq.cpp | 4 +- ginac/function.pl | 4 +- ginac/hash_seed.h | 45 ++++++++++++++++++++++++++++++ ginac/idx.cpp | 4 +- ginac/relational.cpp | 4 +- ginac/symbol.cpp | 5 ++- ginac/symmetry.cpp | 4 +- ginac/wildcard.cpp | 5 ++- 11 files changed, 138 insertions(+), 17 deletions(-) create mode 100644 ginac/crc32.h create mode 100644 ginac/hash_seed.h diff --git a/ginac/Makefile.am b/ginac/Makefile.am index bf091b4..bf20afc 100644 --- a/ginac/Makefile.am +++ b/ginac/Makefile.am @@ -9,7 +9,7 @@ libginac_la_SOURCES = add.cpp archive.cpp basic.cpp clifford.cpp color.cpp \ operators.cpp power.cpp registrar.cpp relational.cpp remember.cpp \ pseries.cpp print.cpp symbol.cpp symmetry.cpp tensor.cpp \ utils.cpp wildcard.cpp \ - remember.h tostring.h utils.h compiler.h \ + remember.h tostring.h utils.h crc32.h hash_seed.h compiler.h \ parser/parse_binop_rhs.cpp \ parser/parser.cpp \ parser/parse_context.cpp \ diff --git a/ginac/basic.cpp b/ginac/basic.cpp index ff1f7a0..f9f18f5 100644 --- a/ginac/basic.cpp +++ b/ginac/basic.cpp @@ -33,6 +33,7 @@ #include "wildcard.h" #include "archive.h" #include "utils.h" +#include "hash_seed.h" #include "inifcns.h" #include @@ -780,8 +781,7 @@ return_type_t basic::return_type_tinfo() const * would all end up with the same hashvalue. */ unsigned basic::calchash() const { - const void* this_tinfo = (const void*)typeid(*this).name(); - unsigned v = golden_ratio_hash((p_int)this_tinfo); + unsigned v = make_hash_seed(typeid(*this)); for (size_t i=0; iop(i).gethash(); diff --git a/ginac/crc32.h b/ginac/crc32.h new file mode 100644 index 0000000..6edd5c6 --- /dev/null +++ b/ginac/crc32.h @@ -0,0 +1,74 @@ +#ifndef GINAC_CRC32_H +#define GINAC_CRC32_H +/** + * CRC32 hash function. Shamelessly stolen from GNU coreutils (cksum.c) + */ +namespace GiNaC +{ +static unsigned const crctab[256] = +{ + 0x00000000, + 0x04c11db7, 0x09823b6e, 0x0d4326d9, 0x130476dc, 0x17c56b6b, + 0x1a864db2, 0x1e475005, 0x2608edb8, 0x22c9f00f, 0x2f8ad6d6, + 0x2b4bcb61, 0x350c9b64, 0x31cd86d3, 0x3c8ea00a, 0x384fbdbd, + 0x4c11db70, 0x48d0c6c7, 0x4593e01e, 0x4152fda9, 0x5f15adac, + 0x5bd4b01b, 0x569796c2, 0x52568b75, 0x6a1936c8, 0x6ed82b7f, + 0x639b0da6, 0x675a1011, 0x791d4014, 0x7ddc5da3, 0x709f7b7a, + 0x745e66cd, 0x9823b6e0, 0x9ce2ab57, 0x91a18d8e, 0x95609039, + 0x8b27c03c, 0x8fe6dd8b, 0x82a5fb52, 0x8664e6e5, 0xbe2b5b58, + 0xbaea46ef, 0xb7a96036, 0xb3687d81, 0xad2f2d84, 0xa9ee3033, + 0xa4ad16ea, 0xa06c0b5d, 0xd4326d90, 0xd0f37027, 0xddb056fe, + 0xd9714b49, 0xc7361b4c, 0xc3f706fb, 0xceb42022, 0xca753d95, + 0xf23a8028, 0xf6fb9d9f, 0xfbb8bb46, 0xff79a6f1, 0xe13ef6f4, + 0xe5ffeb43, 0xe8bccd9a, 0xec7dd02d, 0x34867077, 0x30476dc0, + 0x3d044b19, 0x39c556ae, 0x278206ab, 0x23431b1c, 0x2e003dc5, + 0x2ac12072, 0x128e9dcf, 0x164f8078, 0x1b0ca6a1, 0x1fcdbb16, + 0x018aeb13, 0x054bf6a4, 0x0808d07d, 0x0cc9cdca, 0x7897ab07, + 0x7c56b6b0, 0x71159069, 0x75d48dde, 0x6b93dddb, 0x6f52c06c, + 0x6211e6b5, 0x66d0fb02, 0x5e9f46bf, 0x5a5e5b08, 0x571d7dd1, + 0x53dc6066, 0x4d9b3063, 0x495a2dd4, 0x44190b0d, 0x40d816ba, + 0xaca5c697, 0xa864db20, 0xa527fdf9, 0xa1e6e04e, 0xbfa1b04b, + 0xbb60adfc, 0xb6238b25, 0xb2e29692, 0x8aad2b2f, 0x8e6c3698, + 0x832f1041, 0x87ee0df6, 0x99a95df3, 0x9d684044, 0x902b669d, + 0x94ea7b2a, 0xe0b41de7, 0xe4750050, 0xe9362689, 0xedf73b3e, + 0xf3b06b3b, 0xf771768c, 0xfa325055, 0xfef34de2, 0xc6bcf05f, + 0xc27dede8, 0xcf3ecb31, 0xcbffd686, 0xd5b88683, 0xd1799b34, + 0xdc3abded, 0xd8fba05a, 0x690ce0ee, 0x6dcdfd59, 0x608edb80, + 0x644fc637, 0x7a089632, 0x7ec98b85, 0x738aad5c, 0x774bb0eb, + 0x4f040d56, 0x4bc510e1, 0x46863638, 0x42472b8f, 0x5c007b8a, + 0x58c1663d, 0x558240e4, 0x51435d53, 0x251d3b9e, 0x21dc2629, + 0x2c9f00f0, 0x285e1d47, 0x36194d42, 0x32d850f5, 0x3f9b762c, + 0x3b5a6b9b, 0x0315d626, 0x07d4cb91, 0x0a97ed48, 0x0e56f0ff, + 0x1011a0fa, 0x14d0bd4d, 0x19939b94, 0x1d528623, 0xf12f560e, + 0xf5ee4bb9, 0xf8ad6d60, 0xfc6c70d7, 0xe22b20d2, 0xe6ea3d65, + 0xeba91bbc, 0xef68060b, 0xd727bbb6, 0xd3e6a601, 0xdea580d8, + 0xda649d6f, 0xc423cd6a, 0xc0e2d0dd, 0xcda1f604, 0xc960ebb3, + 0xbd3e8d7e, 0xb9ff90c9, 0xb4bcb610, 0xb07daba7, 0xae3afba2, + 0xaafbe615, 0xa7b8c0cc, 0xa379dd7b, 0x9b3660c6, 0x9ff77d71, + 0x92b45ba8, 0x9675461f, 0x8832161a, 0x8cf30bad, 0x81b02d74, + 0x857130c3, 0x5d8a9099, 0x594b8d2e, 0x5408abf7, 0x50c9b640, + 0x4e8ee645, 0x4a4ffbf2, 0x470cdd2b, 0x43cdc09c, 0x7b827d21, + 0x7f436096, 0x7200464f, 0x76c15bf8, 0x68860bfd, 0x6c47164a, + 0x61043093, 0x65c52d24, 0x119b4be9, 0x155a565e, 0x18197087, + 0x1cd86d30, 0x029f3d35, 0x065e2082, 0x0b1d065b, 0x0fdc1bec, + 0x3793a651, 0x3352bbe6, 0x3e119d3f, 0x3ad08088, 0x2497d08d, + 0x2056cd3a, 0x2d15ebe3, 0x29d4f654, 0xc5a92679, 0xc1683bce, + 0xcc2b1d17, 0xc8ea00a0, 0xd6ad50a5, 0xd26c4d12, 0xdf2f6bcb, + 0xdbee767c, 0xe3a1cbc1, 0xe760d676, 0xea23f0af, 0xeee2ed18, + 0xf0a5bd1d, 0xf464a0aa, 0xf9278673, 0xfde69bc4, 0x89b8fd09, + 0x8d79e0be, 0x803ac667, 0x84fbdbd0, 0x9abc8bd5, 0x9e7d9662, + 0x933eb0bb, 0x97ffad0c, 0xafb010b1, 0xab710d06, 0xa6322bdf, + 0xa2f33668, 0xbcb4666d, 0xb8757bda, 0xb5365d03, 0xb1f740b4 +}; + +static unsigned crc32(const char* c, const unsigned len, const unsigned crcinit) +{ + unsigned crc = crcinit ^ 0xFFFFFFFFU; + for (unsigned i = 0; i < len; ++i) + crc = (crc << 8) ^ crctab[((crc >> 24) ^ c[i]) & 0xFF]; + crc = ~crc & 0xFFFFFFFFU; + return crc; +} +} // namespace GiNaC +#endif /* GINAC_CRC32_H */ + diff --git a/ginac/expairseq.cpp b/ginac/expairseq.cpp index 7284836..1bf6345 100644 --- a/ginac/expairseq.cpp +++ b/ginac/expairseq.cpp @@ -30,6 +30,7 @@ #include "archive.h" #include "operators.h" #include "utils.h" +#include "hash_seed.h" #include "indexed.h" #include @@ -611,8 +612,7 @@ unsigned expairseq::return_type() const unsigned expairseq::calchash() const { - const void* this_tinfo = (const void*)typeid(*this).name(); - unsigned v = golden_ratio_hash((p_int)this_tinfo); + unsigned v = make_hash_seed(typeid(*this)); epvector::const_iterator i = seq.begin(); const epvector::const_iterator end = seq.end(); while (i != end) { diff --git a/ginac/function.pl b/ginac/function.pl index 31f8ba5..e1533be 100644 --- a/ginac/function.pl +++ b/ginac/function.pl @@ -603,6 +603,7 @@ $implementation=< @@ -1062,8 +1063,7 @@ ex function::eval_ncmul(const exvector & v) const unsigned function::calchash() const { - const void* this_tinfo = (const void*)typeid(*this).name(); - unsigned v = golden_ratio_hash(golden_ratio_hash((p_int)this_tinfo) ^ serial); + unsigned v = golden_ratio_hash(make_hash_seed(typeid(*this)) ^ serial); for (size_t i=0; iop(i).gethash(); diff --git a/ginac/hash_seed.h b/ginac/hash_seed.h new file mode 100644 index 0000000..32b057f --- /dev/null +++ b/ginac/hash_seed.h @@ -0,0 +1,45 @@ +#ifndef GINAC_HASH_SEED_H +#define GINAC_HASH_SEED_H +/** + * We need a hash function which gives different values for objects of + * different types. Hence we need some unique integer for each type. + * Fortunately, standard C++ RTTI class `type_info' stores a pointer to + * mangled type name. Normally this pointer is the same for all objects + * of the same type (although it changes from run to run), so it can be + * used for computing hashes. However, on some platforms (such as woe32) + * the pointer returned by type_info::name() might be different even for + * objects of the same type! Hence we need to resort to comparing string + * representation of the (mangled) type names. This is quite expensive, + * so we compare crc32 hashes of those strings. We might got more hash + * collisions (and slower evaluation as a result), but being a bit slower + * is much better than being wrong. + */ +#include +#include +#include "crc32.h" +#include "utils.h" +#ifdef _WIN32 +#define GINAC_HASH_USE_MANGLED_NAME 1 +#endif +namespace GiNaC +{ +#ifndef GINAC_HASH_USE_MANGLED_NAME +static inline unsigned make_hash_seed(const std::type_info& tinfo) +{ + // this pointer is the same for all objects of the same type. + // Hence we can use that pointer + const void* mangled_name_ptr = (const void*)tinfo.name(); + unsigned v = golden_ratio_hash((p_int)mangled_name_ptr); + return v; +} +#else +static unsigned make_hash_seed(const std::type_info& tinfo) +{ + const char* mangled_name = tinfo.name(); + return crc32(mangled_name, std::strlen(mangled_name), 0); +} +#endif +} // namespace GiNaC +#endif /* GINAC_HASH_SEED_H */ + + diff --git a/ginac/idx.cpp b/ginac/idx.cpp index c2565ca..d1a9c49 100644 --- a/ginac/idx.cpp +++ b/ginac/idx.cpp @@ -27,6 +27,7 @@ #include "operators.h" #include "archive.h" #include "utils.h" +#include "hash_seed.h" #include #include @@ -350,8 +351,7 @@ unsigned idx::calchash() const // hash keys. That is, the hash values must not depend on the index // dimensions or other attributes (variance etc.). // The compare_same_type() methods will take care of the rest. - const void* this_tinfo = (const void*)(typeid(*this).name()); - unsigned v = golden_ratio_hash((p_int)this_tinfo); + unsigned v = make_hash_seed(typeid(*this)); v = rotate_left(v); v ^= value.gethash(); diff --git a/ginac/relational.cpp b/ginac/relational.cpp index fc75e68..eff8e94 100644 --- a/ginac/relational.cpp +++ b/ginac/relational.cpp @@ -25,6 +25,7 @@ #include "numeric.h" #include "archive.h" #include "utils.h" +#include "hash_seed.h" #include #include @@ -259,8 +260,7 @@ return_type_t relational::return_type_tinfo() const unsigned relational::calchash() const { - const void* this_tinfo = (const void*)typeid(*this).name(); - unsigned v = golden_ratio_hash((p_int)this_tinfo); + unsigned v = make_hash_seed(typeid(*this)); unsigned lhash = lh.gethash(); unsigned rhash = rh.gethash(); diff --git a/ginac/symbol.cpp b/ginac/symbol.cpp index cb33de7..a736088 100644 --- a/ginac/symbol.cpp +++ b/ginac/symbol.cpp @@ -25,6 +25,7 @@ #include "archive.h" #include "tostring.h" #include "utils.h" +#include "hash_seed.h" #include "inifcns.h" #include @@ -253,8 +254,8 @@ bool symbol::is_equal_same_type(const basic & other) const unsigned symbol::calchash() const { - const void* this_tinfo = (const void*)typeid(*this).name(); - hashvalue = golden_ratio_hash((p_int)this_tinfo ^ serial); + unsigned seed = make_hash_seed(typeid(*this)); + hashvalue = golden_ratio_hash(seed ^ serial); setflag(status_flags::hash_calculated); return hashvalue; } diff --git a/ginac/symmetry.cpp b/ginac/symmetry.cpp index 1de84e6..9e00a8c 100644 --- a/ginac/symmetry.cpp +++ b/ginac/symmetry.cpp @@ -26,6 +26,7 @@ #include "operators.h" #include "archive.h" #include "utils.h" +#include "hash_seed.h" #include #include @@ -185,8 +186,7 @@ int symmetry::compare_same_type(const basic & other) const unsigned symmetry::calchash() const { - const void* this_tinfo = (const void*)typeid(*this).name(); - unsigned v = golden_ratio_hash((p_int)this_tinfo); + unsigned v = make_hash_seed(typeid(*this)); if (type == none) { v = rotate_left(v); diff --git a/ginac/wildcard.cpp b/ginac/wildcard.cpp index 6f96a04..98ff880 100644 --- a/ginac/wildcard.cpp +++ b/ginac/wildcard.cpp @@ -23,6 +23,7 @@ #include "wildcard.h" #include "archive.h" #include "utils.h" +#include "hash_seed.h" #include @@ -106,8 +107,8 @@ unsigned wildcard::calchash() const // this is where the schoolbook method // (golden_ratio_hash(typeid(*this).name()) ^ label) // is not good enough yet... - const void* this_tinfo = (const void*)typeid(*this).name(); - hashvalue = golden_ratio_hash(golden_ratio_hash((p_int)this_tinfo) ^ label); + unsigned seed = make_hash_seed(typeid(*this)); + hashvalue = golden_ratio_hash(seed ^ label); setflag(status_flags::hash_calculated); return hashvalue; } -- 1.5.6.5 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 835 bytes Desc: Digital signature URL: From git at ginac.de Wed Feb 25 12:40:42 2009 From: git at ginac.de (Jens Vollinga) Date: Wed, 25 Feb 2009 12:40:42 +0100 (CET) Subject: [GiNaC-devel] [SCM] GiNaC -- a C++ library for symbolic computations branch, master, updated. release_1-4-0-187-gee1ec9d Message-ID: <20090225114042.654AF5B4042@cebix.net> This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "GiNaC -- a C++ library for symbolic computations". The branch, master has been updated via ee1ec9db30b446d2d6348df2ce758ed2ff62a310 (commit) via 4cf514ec7a3d8dbb447eaa46747f31a9fc9cf159 (commit) from cbba7a5eb9d33003c081a8017dec7da3aa990571 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- commit ee1ec9db30b446d2d6348df2ce758ed2ff62a310 Author: Alexei Sheplyakov Date: Mon Feb 23 14:08:42 2009 +0200 calchash(): work around broken RTTI. Due to the strange (although permitted by the standard) behaviour of C++ RTTI on woe32 calchash() returns different hash values for equal objects. As a result automatic evaluation gets spectacularly broken: examining clifford objects.....({1+t,2+x,3+y,4+z}) - ({1+t,2+x,3+y,4+z}) erroneously returned -{1+t,2+x,3+y,4+z}+{1+t,2+x,3+y,4+z} instead of 0 ({1+t,2+x,3+y,4+z}) - ({1+t,2+x,3+y,4+z}) erroneously returned -{1+t,2+x,3+y,4+z}+{1+t,2+x,3+y,4+z} instead of 0 .({1+t,2+x,3+y,4+z}) - ({1+t,2+x,3+y,4+z}) erroneously returned -{1+t,2+x,3+y,4+z}+{1+t,2+x,3+y,4+z} instead of 0 ({1+t,2+x,3+y,4+z}) - ({1+t,2+x,3+y,4+z}) erroneously returned {1+t,2+x,3+y,4+z}-{1+t,2+x,3+y,4+z} instead of 0 [skipped] .......FAIL: exam_clifford.exe This patch works around `features' of woe32 RTTI, so calchash() works properly. commit 4cf514ec7a3d8dbb447eaa46747f31a9fc9cf159 Author: Alexei Sheplyakov Date: Mon Feb 23 14:03:16 2009 +0200 Fix compilation failure due to (template) operator- defined in factor.cpp GiNaC 1.5.0 fails to compile with g++ 3.4. The fix is simple: declare (and define) operator- (and operator+) only for (univariate) polynomials. ----------------------------------------------------------------------- Summary of changes: ginac/Makefile.am | 2 +- ginac/basic.cpp | 4 +- ginac/crc32.h | 74 ++++++++++++++++++++++++++++++++++++++++++++++++++ ginac/expairseq.cpp | 4 +- ginac/factor.cpp | 32 ++++++++++++++++++++- ginac/function.pl | 4 +- ginac/hash_seed.h | 45 ++++++++++++++++++++++++++++++ ginac/idx.cpp | 4 +- ginac/relational.cpp | 4 +- ginac/symbol.cpp | 5 ++- ginac/symmetry.cpp | 4 +- ginac/wildcard.cpp | 5 ++- 12 files changed, 168 insertions(+), 19 deletions(-) create mode 100644 ginac/crc32.h create mode 100644 ginac/hash_seed.h hooks/post-receive -- GiNaC -- a C++ library for symbolic computations From git at ginac.de Wed Feb 25 12:42:31 2009 From: git at ginac.de (Jens Vollinga) Date: Wed, 25 Feb 2009 12:42:31 +0100 (CET) Subject: [GiNaC-devel] [SCM] GiNaC -- a C++ library for symbolic computations branch, ginac_1-5, updated. release_1-4-0-187-g0256e2f Message-ID: <20090225114231.B71365B4042@cebix.net> This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "GiNaC -- a C++ library for symbolic computations". The branch, ginac_1-5 has been updated via 0256e2fe48a0ecce79c37ac209620ca852b7f11a (commit) via 75b1f2213aa6dc0e563b8ad6202522a5f40cb5be (commit) from cbba7a5eb9d33003c081a8017dec7da3aa990571 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- commit 0256e2fe48a0ecce79c37ac209620ca852b7f11a Author: Alexei Sheplyakov Date: Mon Feb 23 14:08:42 2009 +0200 calchash(): work around broken RTTI. Due to the strange (although permitted by the standard) behaviour of C++ RTTI on woe32 calchash() returns different hash values for equal objects. As a result automatic evaluation gets spectacularly broken: examining clifford objects.....({1+t,2+x,3+y,4+z}) - ({1+t,2+x,3+y,4+z}) erroneously returned -{1+t,2+x,3+y,4+z}+{1+t,2+x,3+y,4+z} instead of 0 ({1+t,2+x,3+y,4+z}) - ({1+t,2+x,3+y,4+z}) erroneously returned -{1+t,2+x,3+y,4+z}+{1+t,2+x,3+y,4+z} instead of 0 .({1+t,2+x,3+y,4+z}) - ({1+t,2+x,3+y,4+z}) erroneously returned -{1+t,2+x,3+y,4+z}+{1+t,2+x,3+y,4+z} instead of 0 ({1+t,2+x,3+y,4+z}) - ({1+t,2+x,3+y,4+z}) erroneously returned {1+t,2+x,3+y,4+z}-{1+t,2+x,3+y,4+z} instead of 0 [skipped] .......FAIL: exam_clifford.exe This patch works around `features' of woe32 RTTI, so calchash() works properly. commit 75b1f2213aa6dc0e563b8ad6202522a5f40cb5be Author: Alexei Sheplyakov Date: Mon Feb 23 14:03:16 2009 +0200 Fix compilation failure due to (template) operator- defined in factor.cpp GiNaC 1.5.0 fails to compile with g++ 3.4. The fix is simple: declare (and define) operator- (and operator+) only for (univariate) polynomials. ----------------------------------------------------------------------- Summary of changes: ginac/Makefile.am | 2 +- ginac/basic.cpp | 4 +- ginac/crc32.h | 74 ++++++++++++++++++++++++++++++++++++++++++++++++++ ginac/expairseq.cpp | 4 +- ginac/factor.cpp | 32 ++++++++++++++++++++- ginac/function.pl | 4 +- ginac/hash_seed.h | 45 ++++++++++++++++++++++++++++++ ginac/idx.cpp | 4 +- ginac/relational.cpp | 4 +- ginac/symbol.cpp | 5 ++- ginac/symmetry.cpp | 4 +- ginac/wildcard.cpp | 5 ++- 12 files changed, 168 insertions(+), 19 deletions(-) create mode 100644 ginac/crc32.h create mode 100644 ginac/hash_seed.h hooks/post-receive -- GiNaC -- a C++ library for symbolic computations From git at ginac.de Wed Feb 25 13:03:40 2009 From: git at ginac.de (Jens Vollinga) Date: Wed, 25 Feb 2009 13:03:40 +0100 (CET) Subject: [GiNaC-devel] [SCM] GiNaC -- a C++ library for symbolic computations branch, ginac_1-5, updated. release_1-4-0-188-g7e14533 Message-ID: <20090225120340.42FB65B4042@cebix.net> This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "GiNaC -- a C++ library for symbolic computations". The branch, ginac_1-5 has been updated via 7e145335f2d185c7e07044be5a758bb8f0f71e29 (commit) from 0256e2fe48a0ecce79c37ac209620ca852b7f11a (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- commit 7e145335f2d185c7e07044be5a758bb8f0f71e29 Author: Jens Vollinga Date: Wed Feb 25 13:07:18 2009 +0100 Preparing for release. ----------------------------------------------------------------------- Summary of changes: NEWS | 4 ++++ configure.ac | 10 ++++++---- 2 files changed, 10 insertions(+), 4 deletions(-) hooks/post-receive -- GiNaC -- a C++ library for symbolic computations From varg at metalica.kh.ua Wed Feb 25 13:41:25 2009 From: varg at metalica.kh.ua (Alexei Sheplyakov) Date: Wed, 25 Feb 2009 14:41:25 +0200 Subject: [GiNaC-devel] [SCM] GiNaC -- a C++ library for symbolic computations branch, ginac_1-5, updated. release_1-4-0-188-g7e14533 In-Reply-To: <20090225120340.42FB65B4042@cebix.net> References: <20090225120340.42FB65B4042@cebix.net> Message-ID: <20090225124125.GA30450@metalica.kh.ua> Hi, On Wed, Feb 25, 2009 at 01:03:40PM +0100, Jens Vollinga wrote: > - Log ----------------------------------------------------------------- > commit 7e145335f2d185c7e07044be5a758bb8f0f71e29 > Author: Jens Vollinga > Date: Wed Feb 25 13:07:18 2009 +0100 > > Preparing for release. > > ----------------------------------------------------------------------- > > Summary of changes: > NEWS | 4 ++++ --- a/NEWS +++ b/NEWS @@ -1,5 +1,9 @@ This file records noteworthy changes. +1.5.1 (25 February 2009) +* Fixed compiling problems with GNU g++ 3.4. +* Fixed broken RTTI on woe32. + Oh, what a nice joke! @@ -14,7 +14,9 @@ dnl When making releases, do dnl 1. Increment ginac_lt_revision dnl 2. If any interfaces have been added, removed, or changed since the last dnl release, increment ginac_lt_current and set ginac_lt_revision to 0. -dnl 3. If any interfaces have been removed since the last release, set +dnl 3. If any interfaces have been added since the last release, increment +dnl ginac_lt_age. +dnl 4. If any interfaces have been removed since the last release, set dnl ginac_lt_age to 0. dnl So far so good... @@ -22,8 +24,8 @@ dnl systems, the numbering is consecutive. It only guarantees that it is dnl increasing. This doesn't matter, though: there is not incurred cost dnl for numbers that are omitted, except for shrinking the available space dnl of leftover numbers. Not something we need to worry about yet. ;-) -m4_define([ginac_lt_current], [0]) -m4_define([ginac_lt_age], [0]) +m4_define([ginac_lt_current], [1]) +m4_define([ginac_lt_age], [1]) m4_define([ginac_lt_revision], [0]) This looks incorrect. We did not add or removed any interfaces, we fixed existing ones. So we should simply increment ginac_lt_revision, and that's it. Best regards, Alexei -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 835 bytes Desc: Digital signature URL: From jensv at nikhef.nl Wed Feb 25 13:46:41 2009 From: jensv at nikhef.nl (Jens Vollinga) Date: Wed, 25 Feb 2009 13:46:41 +0100 Subject: [GiNaC-devel] [SCM] GiNaC -- a C++ library for symbolic computations branch, ginac_1-5, updated. release_1-4-0-188-g7e14533 In-Reply-To: <20090225124125.GA30450@metalica.kh.ua> References: <20090225120340.42FB65B4042@cebix.net> <20090225124125.GA30450@metalica.kh.ua> Message-ID: <49A53DB1.3070805@nikhef.nl> Hi, Alexei Sheplyakov schrieb: > +1.5.1 (25 February 2009) > +* Fixed compiling problems with GNU g++ 3.4. > +* Fixed broken RTTI on woe32. > + > > Oh, what a nice joke! what do you mean? Should we change NEWS? > -m4_define([ginac_lt_current], [0]) > -m4_define([ginac_lt_age], [0]) > +m4_define([ginac_lt_current], [1]) > +m4_define([ginac_lt_age], [1]) > m4_define([ginac_lt_revision], [0]) > > This looks incorrect. We did not add or removed any interfaces, we fixed > existing ones. So we should simply increment ginac_lt_revision, and that's it. But crc32(), crctab[], make_hash_seed() are part of the (public) interface, or not? Regards, Jens From varg at metalica.kh.ua Wed Feb 25 14:50:47 2009 From: varg at metalica.kh.ua (Alexei Sheplyakov) Date: Wed, 25 Feb 2009 15:50:47 +0200 Subject: [GiNaC-devel] [SCM] GiNaC -- a C++ library for symbolic computations branch, ginac_1-5, updated. release_1-4-0-188-g7e14533 In-Reply-To: <49A53DB1.3070805@nikhef.nl> References: <20090225120340.42FB65B4042@cebix.net> <20090225124125.GA30450@metalica.kh.ua> <49A53DB1.3070805@nikhef.nl> Message-ID: <20090225135047.GA32448@metalica.kh.ua> On Wed, Feb 25, 2009 at 01:46:41PM +0100, Jens Vollinga wrote: > Alexei Sheplyakov schrieb: >> +1.5.1 (25 February 2009) >> +* Fixed compiling problems with GNU g++ 3.4. >> +* Fixed broken RTTI on woe32. >> + >> >> Oh, what a nice joke! > > what do you mean? `Fixed broken RTTI on woe32' is a bit sloppy. It might be (mis)interpreted as if we fixed woe32's C++ runtime library itself instead of accommodating GiNaC to its limitations. Hence it sounds a little bit funny. > Should we change NEWS? Yes. I propose the following wording: * Work around weird C++ RTTI behaviour on woe32 so GiNaC works on MinGW again. >> -m4_define([ginac_lt_current], [0]) >> -m4_define([ginac_lt_age], [0]) >> +m4_define([ginac_lt_current], [1]) >> +m4_define([ginac_lt_age], [1]) >> m4_define([ginac_lt_revision], [0]) >> >> This looks incorrect. We did not add or removed any interfaces, we fixed >> existing ones. So we should simply increment ginac_lt_revision, and that's it. > > But crc32(), crctab[], make_hash_seed() are part of the (public) > interface, or not? crc32(), make_hash_seed() are not exported via user visible headers so they are not part of public API/ABI. Also, these functions (and crctab[] variable) are static. They can't be a part of the public interface in first place. Best regards, Alexei -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 835 bytes Desc: Digital signature URL: From jensv at nikhef.nl Wed Feb 25 14:59:24 2009 From: jensv at nikhef.nl (Jens Vollinga) Date: Wed, 25 Feb 2009 14:59:24 +0100 Subject: [GiNaC-devel] [SCM] GiNaC -- a C++ library for symbolic computations branch, ginac_1-5, updated. release_1-4-0-188-g7e14533 In-Reply-To: <20090225135047.GA32448@metalica.kh.ua> References: <20090225120340.42FB65B4042@cebix.net> <20090225124125.GA30450@metalica.kh.ua> <49A53DB1.3070805@nikhef.nl> <20090225135047.GA32448@metalica.kh.ua> Message-ID: <49A54EBC.7040904@nikhef.nl> Hi, Alexei Sheplyakov schrieb: > crc32(), make_hash_seed() are not exported via user visible headers so they > are not part of public API/ABI. Also, these functions (and crctab[] variable) oops, yes, they are not installed. Okay, then I fix the numbers. Regards, Jens From git at ginac.de Wed Feb 25 15:00:48 2009 From: git at ginac.de (Jens Vollinga) Date: Wed, 25 Feb 2009 15:00:48 +0100 (CET) Subject: [GiNaC-devel] [SCM] GiNaC -- a C++ library for symbolic computations branch, ginac_1-5, updated. release_1-4-0-189-g1d0ab62 Message-ID: <20090225140048.EF98C5B4042@cebix.net> This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "GiNaC -- a C++ library for symbolic computations". The branch, ginac_1-5 has been updated via 1d0ab629c691c48e6aa6c291a052f27b726b26ff (commit) from 7e145335f2d185c7e07044be5a758bb8f0f71e29 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- commit 1d0ab629c691c48e6aa6c291a052f27b726b26ff Author: Jens Vollinga Date: Wed Feb 25 15:03:38 2009 +0100 Repairing the preparing of the release. ----------------------------------------------------------------------- Summary of changes: NEWS | 2 +- configure.ac | 6 +++--- 2 files changed, 4 insertions(+), 4 deletions(-) hooks/post-receive -- GiNaC -- a C++ library for symbolic computations From git at ginac.de Wed Feb 25 19:36:04 2009 From: git at ginac.de (Jens Vollinga) Date: Wed, 25 Feb 2009 19:36:04 +0100 (CET) Subject: [GiNaC-devel] [SCM] GiNaC -- a C++ library for symbolic computations tag, release_1-5-1, created. release_1-4-0-189-g1d0ab62 Message-ID: <20090225183605.02B165B4051@cebix.net> This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "GiNaC -- a C++ library for symbolic computations". The tag, release_1-5-1 has been created at 1d0ab629c691c48e6aa6c291a052f27b726b26ff (commit) - Log ----------------------------------------------------------------- commit 1d0ab629c691c48e6aa6c291a052f27b726b26ff Author: Jens Vollinga Date: Wed Feb 25 15:03:38 2009 +0100 Repairing the preparing of the release. ----------------------------------------------------------------------- hooks/post-receive -- GiNaC -- a C++ library for symbolic computations From jensv at nikhef.nl Wed Feb 25 19:41:45 2009 From: jensv at nikhef.nl (Jens Vollinga) Date: Wed, 25 Feb 2009 19:41:45 +0100 Subject: [GiNaC-devel] Release GiNaC 1.5.1 Message-ID: <49A590E9.9010709@nikhef.nl> Hi everybody, GiNaC 1.5.1 is out and available. The changes are: * Fixed compiling problems with GNU g++ 3.4. * Work around weird C++ RTTI behaviour on woe32 so GiNaC works on MinGW again. As always, this release can be downloaded from http://www.ginac.de/Download.html Best wishes, Jens