From kreckel at ThEP.Physik.Uni-Mainz.DE Tue May 2 22:52:58 2000 From: kreckel at ThEP.Physik.Uni-Mainz.DE (Richard B. Kreckel) Date: Tue, 2 May 2000 22:52:58 +0200 (CEST) Subject: [FYI] the potential of GMP -> CLN -> GiNaC boosts Message-ID: Hi, Since GMP3 has been released we are now in the process to adapt CLN to make use of that new library. While GMP3 seems to be much faster than GMP2 (largely because of the support of common new processors like PPro and also due to some improved algorithms with better asymptotic behaviour) and CLN does see a large chunk of this improvement I have the impression that most common symbolic computations don't actually benefit too much from this. Just because I was curious, I have made a preliminary statically linked GiNaC suite of timings, once with the old CLN using GMP2 and once with a CLN using the new GMP3. The results are interesting in a sense that they don't show much improvement. I have marked the tests which make heavy use of the class GiNaC::numeric (and thus are expected to run faster now) with an asterisk, the others with a dash: timing commutative expansion and substitution.... passed - size: 25 50 100 200 w/GMP2: time/s: 0.03 0.16 0.67 2.99 w/GMP3: time/s: 0.04 0.15 0.66 3.01 timing Laurent series expansion of Gamma function.... passed - order: 10 15 20 25 w/GMP2: time/s: 0.130 0.709 3.26 12.65 w/GMP3: time/s: 0.119 0.719 3.209 12.48 timing determinant of univariate symbolic Vandermonde matrices.... passed - dim: 4x4 6x6 8x8 10x10 w/GMP2: time/s: 0.002 0.02 0.299 2.91 w/GMP3: time/s: 0.003 0.02 0.299 2.88 timing determinant of polyvariate symbolic Toeplitz matrices.... passed - dim: 5x5 6x6 7x7 8x8 w/GMP2: time/s: 0.035 0.190 0.959 4.15 w/GMP3: time/s: 0.036 0.179 0.930 4.08 w/GMP2: w/GMP3: timing Lewis-Wester test A (divide factorials). 0.35 0.35 * timing Lewis-Wester test B (sum of rational numbers). 0.027 0.027 * timing Lewis-Wester test C (gcd of big integers). 0.45 0.45 * timing Lewis-Wester test D (sum of rational fcns). 0.00085 0.00086 - timing Lewis-Wester test E (sum of rational fcns). 0.00082 0.00081 - timing Lewis-Wester test F (gcd of 2-var polys). 0.095 0.095 ? timing Lewis-Wester test G (gcd of 3-var polys). 3.35 3.21 ? timing Lewis-Wester test H (det of 80x80 Hilbert). 10.88 10.30 * timing Lewis-Wester test I (invert rank 40 Hilbert). 4.10 3.97 * timing Lewis-Wester test J (check rank 40 Hilbert). 1.90 1.86 * timing Lewis-Wester test K (invert rank 70 Hilbert). 26.34 25.29 * timing Lewis-Wester test L (check rank 70 Hilbert). 10.96 10.70 * timing Lewis-Wester test M1 (26x26 sparse, det). 0.46 0.46 - timing Lewis-Wester test O1 (three 15x15 dets, average)... 49.51 49.31 - timing Lewis-Wester test P (det of sparse rank 101). 5.49 5.49 * timing Lewis-Wester test P' (det of less sparse rank 101). 10.02 9.69 * timing Lewis-Wester test Q (charpoly(P)). 145.71 144.10 * timing Lewis-Wester test Q' (charpoly(P')). 293.92 289.26 * It's embarassing that the four first tests show a common pattern: the new library runs slightly faster with large problem sizes and slower with small once. It's perfectly reproducible. Can anybody suggest a possible explanation for this? Cheers -richy. -- Richard Kreckel From kreckel at ThEP.Physik.Uni-Mainz.DE Fri May 12 16:03:49 2000 From: kreckel at ThEP.Physik.Uni-Mainz.DE (Richard B. Kreckel) Date: Fri, 12 May 2000 16:03:49 +0200 (CEST) Subject: GiNaC 0.6 is on the wire! Message-ID: Good morning everybody! We loudly present a new release of the GiNaC framework for symbolic computation within your favorite programming language. Please hurry up and grab your copy from . Make sure you read the file NEWS to see that we did an awful job trying to break your existing code! Also included in make-target check are some tests invented by R. Lewis and M. Wester, carefully crafted by skilled coders to successfully overheat your CPU and bring down your machine within minutes! Interfacing GiNaC with Cint is also progressing nicely and if nobody angers the gods of computing the world will soon see a fully integrated symbolic C++ interpreter! \begin{SalespersonSpeak} INCREASE PRODUCTIVITY WITH A PROVEN TOOL GiNaC 0.6 provides the right set of tools so that you can be more productive, more effective, and solve more problems. Use GiNaC 0.6 in all phases of your technical projects. Instead of relying on several separate and expensive software packages, GiNaC 0.6 provides a single computing environment for defining and setting up models, analyzing the results both numerically and graphically, and creating technical reports for publication, or e-publication. TRUST THE INNOVATION LEADERS Countless users all over the world have chosen GiNaC's technology as their preferred platform for solving, analyzing, and designing models in their computational projects. Our customers include virtually all major universities and research institutions, and countless corporations. These customers understand that the complexities of modern analytical computation demand the highest levels of computational excellence. With GiNaC 0.6, we continue to earn the trust of customers by delivering new and robust technology. GiNaC 0.6 is the result of over a thousand person-days of advanced research and development. With ignorant quality assurance practices and casual use of customer feedback through nonexistent beta programs, you can have confidence that the results from GiNaC 0.6 will be reliable and accurate. \end{SalespersonSpeak} We hope to see you again soon when we release GiNaC 0.7 and rip our announcement from another major competitor in the field. :-) Happy hacking -richy. -- Richard Kreckel From briggsk at info.bt.co.uk Thu May 18 11:02:48 2000 From: briggsk at info.bt.co.uk (Keith Briggs) Date: Thu, 18 May 2000 10:02:48 +0100 (BST) Subject: 0.6.0 Message-ID: <200005180902.KAA07173@tantalum.bt-sys.bt.co.uk> Dear ginac-bugs at ginac.de, I tried to install 0.6.0 on my RH6.0 linux system. I got these errors: Making install in reference make[2]: Entering directory `/home/install/GiNaC-0.6.0/doc/reference' make[3]: Entering directory `/home/install/GiNaC-0.6.0/doc/reference' make[3]: Nothing to be done for `install-exec-am'. /bin/sh ../../mkinstalldirs /usr/local/share/doc/GiNaC/reference /usr/bin/install -c -m 644 ./*.html /usr/local/share/doc/GiNaC/reference/*.html /usr/bin/install: ./*.html: No such file or directory make[3]: *** [install-data-local] Error 1 make[3]: Leaving directory `/home/install/GiNaC-0.6.0/doc/reference' make[2]: *** [install-am] Error 2 make[2]: Leaving directory `/home/install/GiNaC-0.6.0/doc/reference' make[1]: *** [install-recursive] Error 1 make[1]: Leaving directory `/home/install/GiNaC-0.6.0/doc' make: *** [install-recursive] Error 1 Also, after `make install' I found that my programs would not compile because version.h had not been copied to /usr/local/include/ginac. I had to do this by hand, then my programs would compile. Also, I have a problem with cout<<(log(1+2*x)/2).series(x==0,n); which does not produce its output in ascending order of powers. Thank you, Keith +-------------------------------------------------------------------+ | Dr. Keith M. Briggs, Complexity Research Group, BT Research Labs. | | Adastral Park admin2 pp5, Martlesham Heath, IP5 3RE, Suffolk, UK | | Tel. 01473 641 911 Fax. 01473 647 410. Home tel: 01473 625 972 | | www.bt.com | personal homepage: www.labs.bt.com/people/briggsk2/ | +-------------------------------------------------------------------+ From kreckel at ThEP.Physik.Uni-Mainz.DE Thu May 18 12:11:06 2000 From: kreckel at ThEP.Physik.Uni-Mainz.DE (Richard B. Kreckel) Date: Thu, 18 May 2000 12:11:06 +0200 (CEST) Subject: 0.6.0 In-Reply-To: <200005180902.KAA07173@tantalum.bt-sys.bt.co.uk> Message-ID: Hello Keith, Thank you for your bug report. On Thu, 18 May 2000, Keith Briggs wrote: > I tried to install 0.6.0 on my RH6.0 linux system. > I got these errors: > > Making install in reference > make[2]: Entering directory `/home/install/GiNaC-0.6.0/doc/reference' > make[3]: Entering directory `/home/install/GiNaC-0.6.0/doc/reference' > make[3]: Nothing to be done for `install-exec-am'. > /bin/sh ../../mkinstalldirs /usr/local/share/doc/GiNaC/reference > /usr/bin/install -c -m 644 ./*.html /usr/local/share/doc/GiNaC/reference/*.html > /usr/bin/install: ./*.html: No such file or directory > make[3]: *** [install-data-local] Error 1 > make[3]: Leaving directory `/home/install/GiNaC-0.6.0/doc/reference' > make[2]: *** [install-am] Error 2 > make[2]: Leaving directory `/home/install/GiNaC-0.6.0/doc/reference' > make[1]: *** [install-recursive] Error 1 > make[1]: Leaving directory `/home/install/GiNaC-0.6.0/doc' > make: *** [install-recursive] Error 1 This is a known bug that has already been fixed. > Also, after `make install' I found that my programs would not > compile because version.h had not been copied to /usr/local/include/ginac. > I had to do this by hand, then my programs would compile. This is an unknown bug I have just fixed. I guess we should upload a package where those problems are fixed today. > Also, I have a problem with > cout<<(log(1+2*x)/2).series(x==0,n); > which does not produce its output in ascending order of powers. This is not a bug, it's a feature (tm). The order in which terms are printed is the raw order, determined by their hash-values. When you print a pseries object, it just converts everything to a polynomial. It can become even somewhat more surprising, as commented in the method: void pseries::print(ostream &os, unsigned upper_precedence) const { debugmsg("pseries print", LOGLEVEL_PRINT); // This could be made better, since series expansion at x==1 might print // -1+2*x+Order((-1+x)^2) instead of 1+2*(-1+x)+Order((-1+x)^2), which is // correct but can be rather confusing. convert_to_poly().print(os, upper_precedence); } Maybe somebody should write something more elaborate here? Regards -richy. -- Richard Kreckel From kreckel at ThEP.Physik.Uni-Mainz.DE Tue May 30 10:56:05 2000 From: kreckel at ThEP.Physik.Uni-Mainz.DE (Richard B. Kreckel) Date: Tue, 30 May 2000 10:56:05 +0200 (CEST) Subject: throwing aborts, or: libtool sucks, or: slink sucks even more Message-ID: Hi everybody, The issue of the nasty crashes whenever something is thrown internally (as in .normal(), if the heuristic algorithm failed or in .series() for functions with poles) came up last week. Finally it is becoming clear what's happening. series(tgamma(x),x==0,1) crashed reproducibly when linked dynamically, either in ginsh, ginaccint or elsewhere. Let me explain what's happening. So I am no longer to blame. :-) GiNaC 0.6.1 got an updated libtool from FSF (1.3.4 instead of 1.3.3) and that libtool has changed it's behaviour for linking: $ libtool --mode=link c++ ... uses $CC for linking instead of c++, as it used to be. Libtool's documentation does have something to say about this: > [...] running the C++ compiler directly may lead to problems related > with inter-library dependencies. > > The conclusion is that libtool is not ready for general use for C++ > libraries.[...] > > Furthermore, you'd better find out, at configure time, what are the C++ > Standard libraries that the C++ compiler will link in by default, and > explicitly list them in the link command line. Hopefully, in the future, > libtool will be able to do this job by itself. I am somewhat clueless what those `problems related with inter-library dependencies' might be (there seems to be a gap in the mailing list archives). Well, the day before yesterday they have released libtool 1.3.5 but that doesn't change much. Anyhow, the trouble starts only when you use jurrasic compilers. And Debian/Slink does precisely this: gcc (used for linking) is 2.7.2.3 while c++ (used for compiling) is 2.91.60. Makes the solution pretty obvious: Just exporting CC=egcc prior to configuring solves all problems. Big deal. Or upgrading to Potato (if they manage to release it some lucky day). Happy hacking -rbk. -- Richard Kreckel From kreckel at ThEP.Physik.Uni-Mainz.DE Tue May 30 21:56:45 2000 From: kreckel at ThEP.Physik.Uni-Mainz.DE (Richard B. Kreckel) Date: Tue, 30 May 2000 21:56:45 +0200 (CEST) Subject: throwing aborts, or: libtool sucks, or: slink sucks even more In-Reply-To: Message-ID: Somehow, Bruno's answer didn't make it into the list. I forward it herewith: > Richard Kreckel writes: > > > GiNaC 0.6.1 got an updated libtool from FSF (1.3.4 instead of 1.3.3) and > > that libtool has changed it's behaviour for linking: > > $ libtool --mode=link c++ ... > > uses $CC for linking instead of c++, as it used to be. > > Like you, I consider this a bug. > > > Libtool's documentation does have something to say about this: > > > The conclusion is that libtool is not ready for general use for C++ > libraries. You should avoid any global or static variable > initializations that would cause an "initializer element is not > constant" error if you compiled them with a standard C compiler. > > Ha! CLN is full of such static variable initializations. > > > I am somewhat clueless what those `problems related with inter-library > > dependencies' might be (there seems to be a gap in the mailing list > > archives). > > They probably mean the order of initialization of static > initializers. Precisely the thing that cln's CL_REQUIRE solves. > > > Anyhow, the trouble starts only when you use jurrasic compilers. And > > Debian/Slink does precisely this: gcc (used for linking) is 2.7.2.3 while > > c++ (used for compiling) is 2.91.60. Makes the solution pretty obvious: > > Just exporting CC=egcc prior to configuring solves all problems. Big > > deal. Or upgrading to Potato (if they manage to release it some lucky > > day). > > Therefore, if I were you, I'd do three things: > > - Patch the local copy of ltmain.sh to use the passed command, not > $CC, in link mode. > > - Tell in the documentation that $CC and $CXX should fit together, > i.e. if one is gcc-x.y then the other should be g++-x.y. > > - Tell in the documentation that g++ 2.7.x won't work because it > doesn't have working exception support. > > Bruno Update: Patching ltmain.sh is probably unnecessary. The systems where this happened are Debian/Slink with a patched egcs, since the original from Debian isn't able to parse CLN-headers anyhow (thanks to some people at Debian who broke it, the upstream versions are all fine). It doesn't strike CLN anyhow, not even while linking tests and benchmarks since there libtool decides to use c++, which is fine. It only hurts when exceptions are thrown inside a library. I'll aplly patch 2, then. :-) Regards -richy. PS: I guess to `throw' an exception stems from to `throw up'. -- Richard Kreckel