- GiNaC-devel - ginac.de

Announcing GiNaC 1.1.4
by Richard B. Kreckel 17 Oct '03

17 Oct '03

* It has defied the world's greatest mathematicians. * It lies in wait wherever problems gather. * It is a timeless force with the power to change the course of history. Dear software aficionado, It is our pleasure to introduce GiNaC release 1.1.4. For the true software collecting enthusiast, this is a release like no other -- explaining, illuminating, and illustrating in depth how the bits, bytes and exabytes of the computing machinery more often than not solve problems of undreamed complexity. GiNaC 1.1.4 -- an opus like no other available today -- will bring you to the crossroads of mathematics and computing. Quite simply, GiNaC-1.1.4 is an unparalleled resource no serious software connoisseur can afford to overlook. Take advantage of this singular opportunity and download your very own copy today from URL <ftp://ftpthep.physik.uni-mainz.de/pub/GiNaC>. Best regards -rbk. -- Richard B. Kreckel <Richard.Kreckel(a)GiNaC.DE> <http://www.ginac.de/~kreckel/>

1 0

how to construct a ex in GiNaC
by cbq 17 Oct '03

17 Oct '03

I read the GiNaC code ,found a question. Under GiNaC namespace ,the under code works well. //***this is my code: ............ #include "ginac/ginac.h" using namespace GiNaC; ............ int main(void) { symbol a("a"),b("b"); ex ex0(a+b); cout<<"ex0 = "<<ex0<<endl; return 0; } // end the code but i find nothing about method ex(symbol) in GiNaC. how does the above statement ex ex0(a) work? help me !! thanks! best regards, Boqun Cheng 2003.10.17

2 2

installation problem and/or internal error of GiNaC 1.1.3
by anaximander＠gmx.de 29 Sep '03

29 Sep '03

Hallo (in Mainz spricht man noch Deutsch, oder?) anbei schicke ich ein C++ Programm, das bei der Ausfuehrung (bei mir) auf zwei interne Fehler in GiNaC 1.1.3 verweist. Allerdings war, trotz neuester Versionen sämtlicher Bibliotheken, schon die Kompilierung von GiNaC 1.1.3 nicht ganz erfolgreich Ein Test misslang: examining series expansion.........../run_exams: line 3: 12967 segment fault Ich hab's zu Probezwecken dennoch installiert. Alle technischen Details, Compilerversionen etc stehen in der C++ Datei. Mit vielen Gruessen, und Dank fuer euer tolles System!! Volkmar Klatt PS: Habe auf einem anderen Rechner auch die Intel Compiler Version 7.1 installiert, nur falls Testpersonen gesucht werden... -- NEU FÜR ALLE - GMX MediaCenter - für Fotos, Musik, Dateien... Fotoalbum, File Sharing, MMS, Multimedia-Gruß, GMX FotoService Jetzt kostenlos anmelden unter http://www.gmx.net +++ GMX - die erste Adresse für Mail, Message, More! +++

2 1

improvement for error message.
by Chris Dams 18 Sep '03

18 Sep '03

Hello, In the function ex::subs(const ex & e, unsigned options) if the first argument is neither a relation_equal nor a list, the error message "basic::subs(ex): argument must be a list" gets thrown. I think it would be a good idea to change this into "basic::subs(ex): argument must be a relation_equal or list". Imagine me trying to type a relation_equal, getting some parentheses wrong and ending up with something that is not a relation_equal nor a list. In that case the former error message makes me think "when did it happen that I cannot use a relation anymore as the argument of a substitution". The latter error message might put me on the right track of starting to wonder why the thing I thought was a relation turns out not to be. Bye, Chris Dams

2 2

Re: GiNaC/ginac matrix.cpp matrix.h
by Richard B. Kreckel 24 Aug '03

24 Aug '03

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.

2 2

GiNaC 1.1.3 released
by Christian Bauer 22 Aug '03

22 Aug '03

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<T> template intended as a drop-in replacement for std::map<ex, T, ex_is_less> 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/

1 0

GiNaC 1.1.2 now available
by Christian Bauer 11 Aug '03

11 Aug '03

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/

1 0

RFC: print() double dispatch
by Christian Bauer 17 Jul '03

17 Jul '03

Hi! GiNaC objects can be printed in a variety of different formats. Originally, there were separate virtual methods for each output type (with different parameter lists): basic::print(...) basic::printtree(...) basic::printcsrc(...) etc. This made adding new output types (LaTeX output was planned at that time) cumbersome, as the corresponding method would have to be implemented for every single class, even if the output wasn't different from that of any of the existing output types. In GiNaC 0.8.0, this was radically changed by creating a hierarchy of "print_context" classes, corresponding to the output types, and reducing the print methods to a single one that accepts a print_context object as an argument: basic::print(const print_context &, ...) The implementations of print() for each class then perform a type switch on the actual (dynamic) type of the passed print_context. This design later also proved useful for adding stream manipulators ("cout << latex" etc.). It still has problems, though: - It's not possible for GiNaC users to add new output types that work with existing classes without modifying and recompiling GiNaC (e.g. you could implement a print_fortran class but you need to change power::print() to have powers printed in the proper way). - There is no proper overload resolution performed with respect to the print_context type. You can't easily make a class have a different csrc output (with all other output types being the same) than its parent without manually adding fallback code. This is already a problem with print_tree which produces output that is radically different from any other print_context type (see also utils.h/DEFAULT_PRINT). - There are some design issues with type switches, the most severe being that the order of tests matters when dealing with class hierarchies (e.g. an "if (is_a<print_csrc_cl_N>(c))" must come before an "if (is_a<print_csrc>(c))", otherwise it won't work as expected). A swift design analysis yields that what's really needed here is double dispatch, the ability to dispatch methods depending on the dynamic type of two objects (the algebraic object and the print_context object) which C++, unfortunately, doesn't provide. So this behavior has to be emulated. It is tempting to use visitors here, especially the kind that is already implemented in GiNaC 1.2. For every print_context type, there would be a corresponding visitor class (they even have the proper overload resolution already) but this setup would make adding new algebraic classes to GiNaC impossible, as you couldn't add the required "visit(const myclass &)" function to an existing visitor (sudden crazy thought: might it be possible to apply the visitor scheme to the visitors themselves to achieve that? Probably just results in an unmaintainable mess of NxM classes...). Anyway, I have a working test implementation of a possible double dispatcher for print(). First, the good news: - It appears to work perfectly. - It's dynamic: you can change print methods at runtime. - It's backwards compatible: basic::print() remains a virtual function with the same arguments, so derived classes can overload it as before. They won't get any of the benefits of the new dispatcher then, though. - In any case, unless you write your own symbolic classes you won't notice any difference. The bad news: - It's slower than the current print(). It performs a few virtual function calls and vector lookups, but if the types match it still dispatches in constant time. I doubt that the efficiency of print() is of much importance, though. - Specifying print methods for classes is a little awkward (see below). Print methods are specified in a way that resembles the specification of eval() etc. methods for functions (and designed in a way to allow possible future extension with more per-class attributes): class foo : public basic { GINAC_DECLARE_REGISTERED_CLASS(foo, basic) public: void do_print(const print_context & c, unsigned level) const; void do_print_csrc(const print_csrc & c, unsigned level) const; }; GINAC_IMPLEMENT_REGISTERED_CLASS_OPT(foo, basic, print_func(&foo::do_print).print_func(&foo::do_print_csrc)) class bar : public foo { GINAC_DECLARE_REGISTERED_CLASS(bar, foo) public: // methods can also be static members, and even ordinary global functions static void do_print_csrc(const bar & obj, const print_csrc & c, unsigned level) const; }; GINAC_IMPLEMENT_REGISTERED_CLASS_OPT(bar, foo, print_func(&bar::do_print_csrc)) Now, when you call bar::print() with a print_csrc or derived type, it calls bar::do_print_csrc(), with any other print_context object it calls foo::do_print(). There is also a global function set_print_func() that allows changing the methods at run-time. So to get proper Fortran output for powers, you can do void print_power_fortran(const power & p, const print_fortran & c, unsigned level) { ... } set_print_func(print_power_fortran); Another example for a possible application would be to change the LaTeX output of indexed objects. How it works: - Each print_context type gets a unique ID number, similar to the tinfo_key of the algebraic classes, but assigned automatically. - There are convenience macros GINAC_DECLARE_PRINT_CONTEXT and GINAC_IMPLEMENT_PRINT_CONTEXT that work similar to the corresponding macros for algebraic classes. Their main purpose is to handle said ID number. - registered_class_info is augmented by a vector that contains (possibly NULL) pointers (actually somewhat generalized functors) to the methods for each output type. The print_context ID is used as the vector index. Thus, each class gets its own dispatch table for print(). - basic::print() performs the actual method lookup using the dynamic type of the algebraic object (from where it obtains the method table) and the ID number of the passed print_context object. If no method for that combination was registered, it repeats the process with the parent print_context class. If still no method is found, it repeats the process with the method vector of the parent algebraic class (stopping at the basic class itself). Overload resolution is thus first performed on the type of the algebraic object, then on the type of the print_context object. This matches the current behavior of print(). The current test implementation still has one drawback, though: when specifying a method, the types of the two objects for which this method will be registered are automatically (via some template magic) inferred from the argument types of the supplied function. That is, a "do_print(const lst &, const print_csrc &)" can only be used for the lst/print_csrc combination of types. If you want to, for example, use the same generic "my_print(const basic &, const print_myformat &)" function for a set of different algebraic types, you have to write trampolines like "my_print(const foo &, const print_myformat &)" etc. On the positive side, though, you don't have to explicitly specify the classes via template parameters when registering methods as you have to with most other implementations of double dispatch in C++ (e.g. you would have to write "set_print_func<power, print_fortran>(...)", "print_func<bar, print_csrc>(&bar::do_print_csrc)" etc.). I guess the implementation can be changed to allow the explicit specification of the classes for which a method is to be registered, but then they would always need to be specified. Which way is better? I don't know... Planned future work: - The default output format gets its own context type (print_dflt?), rather than the base class print_context. This will solve the print_tree problem. - Extend this scheme to GiNaC functions, making it possible to, e.g. have abs(x) printed as |x| in LaTeX mode, fabs(x) in C++ mode, etc. Questions? Comments? Suggestions? Do we need this at all, or is the current print() implementation good enough? Bye, Christian -- / Physics is an algorithm \/ http://www.uni-mainz.de/~bauec002/

1 0

patch for container.h
by Chris Dams 14 Jul '03

14 Jul '03

Hello, I found out that if the subs() method does a substitution on a lst the tinfo flag is not set properly. This then gives all kinds of weirdness in the canonical ordering. The solution is to set the tinfo correctly on two of the constructors in container.h . Also, it seems that if one of the expressions in a container is changed by a subs(), still subs_one_level() is called on that container. I think this is wrong. A patch is attached. Bye, Chris Dams

2 1

GiNaC CVS restructured
by Christian Bauer 02 Jul '03

02 Jul '03

Hi! Due to some misunderstanding about the use of CVS branches on our part, the GiNaC CVS was organized in an inconvenient way: +-> GiNaC 1.1 | +-> GiNaC 1.2 | [+-> GiNaC 1.3 etc.] | ... HEAD (GiNaC 1.0) This made the main trunk essentially obsolete and, if continuing in this fashion, would cause longer and longer CVS revision numbers for subsequent versions of GiNaC. The Right Way to set up the branches would have been to create a new branch for every _stable_ version, instead of every development version, like this: +-> GiNaC 1.0 +-> GiNaC 1.1 | ... HEAD (GiNaC 1.2) We will use this system for any further GiNaC development. Unfortunately, it is not possible to rearrange an existing CVS tree, but I have reorganized it as best as possible by branching off GiNaC 1.0 from the current HEAD, merging the changes from 1.0.14 to 1.2 into the main trunk, and deleting the old branch tag for 1.2. So it currently looks like this: +-> GiNaC 1.1 | +-> dead-end (former 1.2) +-> GiNaC 1.0 HEAD (GiNaC 1.2) Ugly, but it achieves the desired effect, with minor annoyances: - the last update to the main trunk contains all changes from 1.0.14 thru 1.1.x and 1.2, so the ability to backtrack the changes one-by-one is gone for this update. - there's a dangling anonymous branch for what formerly was 1.2; I don't think that can be remedied, though. As usual, a specific branch of GiNaC may be checked out from the CVS using "cvs checkout -r branch_tag GiNaC", but the meaning of the tags has now changed a little: old new <no tag specified> GiNaC 1.0 GiNaC 1.2 -r ginac_1-0 N/A GiNaC 1.0 -r ginac_1-1 GiNaC 1.1 GiNaC 1.1 -r ginac_1-2 GiNaC 1.2 N/A Fortunately, users of the current stable version 1.1 won't notice any difference and don't need to take any action. Sorry for the inconvenience, Christian -- / Physics is an algorithm \/ http://www.uni-mainz.de/~bauec002/

1 0