- GiNaC-devel - ginac.de

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

patch for unarchiving
by Chris Dams 30 Jun '03

30 Jun '03

Hello, I found out that if an add or a mul are unarchived no sorting of terms or factors occurs. Since the canonical ordering depends on the order in which symbols are declared and thus may well be different in the archiving and the unarchiving program, I think this is wrong. A patch is attached that is supposed to solve this. Bye, Chris Dams

2 1

typing error in mul.cpp
by Chris Dams 20 Jun '03

20 Jun '03

Hello nice GiNaC people, Could you please change the line for (its = ls.begin(), itr != lr.begin(); its != ls.end(); ++its, ++itr) that occurs in the file mul.cpp in the function mul::algebraic_subs_mul into for (its = ls.begin(), itr = lr.begin(); its != ls.end(); ++its, ++itr) (i.e., remove an exclamation mark). This should give less segmentation faults in my programs. Bye, Chris Dams

2 3

GiNaC 1.1.1 released
by Christian Bauer 18 Jun '03

18 Jun '03

Hi! With one last-minute bug-fix sneaked in by the ever-helpful Chris Dams, we'd like to present GiNaC 1.1.1 which is crunchy on the outside but soft and delicious on the inside: - lst (and exprseq) provide iterators for read-only element access. For sequential access this is one order faster than using op(). - Implemented relational::subs() (this was done in 1.0.9 but inadvertently omitted from the 1.1 branch). - pole_error and do_taylor are available to library users. - Added on-line help and Tab-completion for print(), iprint(), print_latex() and print_csrc() in ginsh. Get it from your favorite FTP server: ftp://ftpthep.physik.uni-mainz.de/pub/GiNaC There's nobody here to drink champagne with, so I can save to money for buying more C++ books... Happy computing, Christian -- / Physics is an algorithm \/ http://www.uni-mainz.de/~bauec002/

1 0