From kreckel at ThEP.Physik.Uni-Mainz.DE Fri Dec 3 20:51:00 1999 From: kreckel at ThEP.Physik.Uni-Mainz.DE (Richard B. Kreckel) Date: Fri, 3 Dec 1999 20:51:00 +0100 (CET) Subject: :-) Message-ID: Aha, I just found this line in the FTP logs: Mon Nov 29 22:38:38 1999 11 ns.maplesoft.on.ca 337437 /pub/GiNaC/GiNaC-0.4.0.tar.bz2 b _ o a mozilla@ ftp 0 * Cheers -richy. -- Richard B. Kreckel From kreckel at ThEP.Physik.Uni-Mainz.DE Tue Dec 14 16:20:25 1999 From: kreckel at ThEP.Physik.Uni-Mainz.DE (Richard B. Kreckel) Date: Tue, 14 Dec 1999 16:20:25 +0100 (CET) Subject: Version 0.4.1 Message-ID: Hello all, Apologies if you got this mail twice, but the set of people on ginac-list and ginac-devel is neither disjoint nor is one a subset of the other... This is to notify you that we've uploaded version 0.4.1 of GiNaC yesterday. The updated documentation is sitting on as well. Please read the News if you are curious on what has changed (it ain't anything dramatic). Check it out, test it, submit bug-reports and (if possible) fixes! Just to keep people informed about current development, let me mention that the next release will probably feature an interface to the CINT C++ interpreter by Masaharu Goto. This will allow people to write C++ scripts interactively and to compile them later. We'll get another interactive interface to GiNaC besides ginsh this way---one with all loop constructs, conditionals and containers known from C++. Currently there are still some weirdnesses concerning automatic promotion of types which are hopefully fixed soon but we are already quite excited about the new possibilities. happy hacking -rbk. -- Richard Kreckel From cbauer at ThEP.Physik.Uni-Mainz.DE Mon Dec 20 17:06:09 1999 From: cbauer at ThEP.Physik.Uni-Mainz.DE (Christian Bauer) Date: Mon, 20 Dec 1999 17:06:09 +0100 (CET) Subject: collect() bug Message-ID: Hi! Consider this: > collect((1-t^2)/(1+t),t); (t+1)^(-1) This is clearly wrong... Bye, Christian -- / Coding on PowerPC and proud of it \/ http://www.uni-mainz.de/~bauec002/ From Alexander.Frink at Uni-Mainz.DE Mon Dec 20 17:15:35 1999 From: Alexander.Frink at Uni-Mainz.DE (Alexander Frink) Date: Mon, 20 Dec 1999 17:15:35 +0100 (CET) Subject: collect() bug In-Reply-To: Message-ID: On Mon, 20 Dec 1999, Christian Bauer wrote: > > collect((1-t^2)/(1+t),t); > (t+1)^(-1) > > This is clearly wrong... The problem is that degree() and ldegree() assume polynomials as input and do not check the result: GiNaCcint> cout << degree((1-pow(ex(t),ex(2)))/(1+t),t) << endl; 1 GiNaCcint> cout << ldegree((1-pow(ex(t),ex(2)))/(1+t),t) << endl; 0 Maple returns FAIL for these expressions. -- Alexander Frink E-Mail: Alexander.Frink at Uni-Mainz.DE Institut fuer Physik Phone: +49-6131-3923391 Johannes-Gutenberg-Universitaet D-55099 Mainz, Germany From kreckel at ThEP.Physik.Uni-Mainz.DE Thu Dec 23 03:44:31 1999 From: kreckel at ThEP.Physik.Uni-Mainz.DE (Richard B. Kreckel) Date: Thu, 23 Dec 1999 03:44:31 +0100 (CET) Subject: porting status (bad news) Message-ID: Ok, here is a little update on what's happening when you dare to use GCC 2.96. Actually, I'm talking about the current CVS-snapshot, which claims to be 2.96 according to __GNUC__ and __GNUC_MINOR__. (And, yes, I have tried the last two *official* snapshots too.) First of all, CLN has to be recompiled because otherwise it aborts at each exception thrown. (This is business as usual, I don't know why this is so and have asked B. Haible for a hint.) If one tries, one runs into problems because the new compiler complains: `void () ()' cannot be `const'-, `volatile'-, or `restrict'-qualified I have made a quick hack around this problem in cl_macros.h but then one runs into trouble again with internal compiler errors, always in `scan_region', at except.c:2710 on different CLN-modules. (Bugreport for gcc-bugs is already submitted.) One can get around this problem by fiddling with optimization options but this does not seem to built a useful library then, since it sometimes fails at some of the random checks. :-( If one insists and builts GiNaC, ginsh and whatnot against this library it fails at every test once optimization is switched on. Omitting optimization results in the follwing fiasco: checking several ex-bugs just out of pure paranoia... failed (NaNs) checking output of numeric types... passed (0.03s) checking consistency of numeric types... passed (0.04s) checking power laws... passed (NaNs) checking commutative expansion and substitution... passed (NaNs) checking consistency of symbolic functions... failed (NaNs) checking symbolic differentiation... passed (NaNs) checking polynomial GCD computation... passed (NaNs) checking rational function normalization... passed (NaNs) checking symbolic matrix manipulations... passed (NaNs) checking linear solve... passed (NaNs) checking series expansion... passed (NaNs) error: something went wrong. (2 individual failures) please check result.out against result.ref for more details. happy debugging! Comparing output... result.ref result.out differ: char 53, line 2 FAIL: run_checks =================== 1 of 1 tests failed =================== make[2]: *** [check-TESTS] Error 1 make[2]: Leaving directory `/home/kreckel/projects/GiNaC/check' make[1]: *** [check-am] Error 2 make[1]: Leaving directory `/home/kreckel/projects/GiNaC/check' make: *** [check-recursive] Error 1 higgsino:~/projects/GiNaC$ diff check/result.out check/result.ref 2c2 < e = x*y*z; f = y*z; expand(e/f) erroneously returned x --- > (no output) 16c16 < sin(n*Pi) with integer n does not always return exact 0 --- > (no output) Both error-reports are *logically* wrong (the first one is obvious). Also, the NaN seconds are quite funny, they go away as soon as one tries to trace down their origin. Holy shit, GCC seems to be rather broken at present. The good news is that the more restrictive preprocessor didn't find any mistakes in GiNaC itself. Happy hacking -rbk. PS: No, my system's clock is fine. :-( -- Richard Kreckel