From Christian.Bauer at Uni-Mainz.DE Mon Aug 11 18:58:55 2003 From: Christian.Bauer at Uni-Mainz.DE (Christian Bauer) Date: Mon, 11 Aug 2003 18:58:55 +0200 Subject: GiNaC 1.1.2 now available Message-ID: <20030811165855.GE28673@thep.physik.uni-mainz.de> Hello! We haven't had an update in a while, and the radical new features of GiNaC 1.2 are taking a bit longer, so I've packed up the latest fixes of the 1.1 line in a nice release: GiNaC 1.1.2 - Fixed a bug in the unarchiving of sums and products: terms were not reordered in a canonical way. - Fixed a bug in normal()/numer_denom(): denominator was not made unit normal if it was a simple number. - Improved the speed of subs() in some cases. As usual, it's on ftp://ftpthep.physik.uni-mainz.de/pub/GiNaC For oldskool fans, there's also a GiNaC 1.0.15 that contains the same two bug fixes. Bye, Christian (who has nearly completed liquefaction; what's the boiling point of human tissue?) -- / Physics is an algorithm \/ http://www.uni-mainz.de/~bauec002/ From Christian.Bauer at Uni-Mainz.DE Fri Aug 22 16:38:30 2003 From: Christian.Bauer at Uni-Mainz.DE (Christian Bauer) Date: Fri, 22 Aug 2003 16:38:30 +0200 Subject: GiNaC 1.1.3 released Message-ID: <20030822143830.GF1939@thep.physik.uni-mainz.de> Hello! Desparate for an excuse to open a bottle of wine (because Booze really satisfies: Booze takes a dull coding session and makes it better. A day without Booze is like a day without sunshine. This GiNaC release is brought to you by the National Booze Council. Remember: Booze makes you popular and heals all wounds.) we decided to release GiNaC 1.1.3, featuring: - New symbolic functions for better integration with nestedsums: (multiple) polylogarithm Li(), Nielsen's generalized polylogarithm S(), harmonic polylogarithm H(), and multiple zeta value mZeta(). - A new exhashmap template intended as a drop-in replacement for std::map using GiNaC's hashing algorithms. It should come as no surprise to you that you can download it from ftp://ftpthep.physik.uni-mainz.de/pub/GiNaC/ Have a nice weekend, Christian -- / Physics is an algorithm \/ http://www.uni-mainz.de/~bauec002/ From kreckel at thep.physik.uni-mainz.de Sun Aug 24 20:54:19 2003 From: kreckel at thep.physik.uni-mainz.de (Richard B. Kreckel) Date: Sun, 24 Aug 2003 20:54:19 +0200 (CEST) Subject: GiNaC/ginac matrix.cpp matrix.h In-Reply-To: <200308241851.h7OIpCQB005062@higgs.physik.uni-mainz.de> Message-ID: On Sun, 24 Aug 2003, Christian Bauer wrote: > Modified Files: > matrix.cpp matrix.h > Log Message: > - charpoly(): lambda is now a "const ex &" instead of a "const symbol &" Is this a speed issue or something else? -richy. From Christian.Bauer at Uni-Mainz.DE Sun Aug 24 21:05:57 2003 From: Christian.Bauer at Uni-Mainz.DE (Christian Bauer) Date: Sun, 24 Aug 2003 21:05:57 +0200 Subject: GiNaC/ginac matrix.cpp matrix.h In-Reply-To: References: <200308241851.h7OIpCQB005062@higgs.physik.uni-mainz.de> Message-ID: <20030824190557.GH1939@thep.physik.uni-mainz.de> Hi! On Sun, Aug 24, 2003 at 08:54:19PM +0200, Richard B. Kreckel wrote: > > Log Message: > > - charpoly(): lambda is now a "const ex &" instead of a "const symbol &" > > Is this a speed issue or something else? I see no reason why lambda should be restricted to symbols. The implementation of the algorithm doesn't require it. Bye, Christian -- / Physics is an algorithm \/ http://www.uni-mainz.de/~bauec002/ From kreckel at thep.physik.uni-mainz.de Sun Aug 24 21:34:51 2003 From: kreckel at thep.physik.uni-mainz.de (Richard B. Kreckel) Date: Sun, 24 Aug 2003 21:34:51 +0200 (CEST) Subject: GiNaC/ginac matrix.cpp matrix.h In-Reply-To: <20030824190557.GH1939@thep.physik.uni-mainz.de> Message-ID: Hi, On Sun, 24 Aug 2003, Christian Bauer wrote: > On Sun, Aug 24, 2003 at 08:54:19PM +0200, Richard B. Kreckel wrote: > > > Log Message: > > > - charpoly(): lambda is now a "const ex &" instead of a "const symbol &" > > > > Is this a speed issue or something else? > > I see no reason why lambda should be restricted to symbols. The implementation > of the algorithm doesn't require it. In this case, you're right. Leverrier's algorithm doesn't require it and determinants don't require it either. Okay. C'mon, that answer was trivial! I was just panicking over object fusion, but it seems that the doors to chaos and madness are rather closed in GiNaC 1.2: As part of the GiNaC evolution towards a modular bridge, some functions received an ex as argument instead of a symbol. Kompatibility will be maintained by ex representing symbols? On Sun, 24 Aug 2003, Christian Bauer wrote to ginac-cvs at ginac.de: > Modified Files: > ex.h ex.cpp > Log Message: > - implemented object fusion as proposed by Richy > - unit(), content() and primpart() take a "const ex &" instead of a > "const symbol &". degree(), coeff(), collect() etc. have dropped the > restriction to symbols a long time ago, so there's no reason for these > function to keep it. That may be somwhat dangerous, but in the end it's great news. What I would now like to research are the options to put a symbolic class derived from ex (withoug vtbl/vptr) at the interface side and thus complete the bridge pattern even more (following CLN's design). This would also completely avoid confusing code like this one: On Thu, 10 Jul 2003, Christian Bauer wrote to ginac-list at ginac.de: > because the symbol objects in the expression are heap-allocated copies > of "a" and "b", but this works: > > symbol &a_sym = *new symbol("a"); a_sym.setflag(status_flags::dynallocated); > symbol &b_sym = *new symbol("b"); b_sym.setflag(status_flags::dynallocated); > ex a = a_sym, b = b_sym; I'll keep you posted. Regards -richy. -- Richard B. Kreckel