- GiNaC-devel - ginac.de

expand()
by Stefan Weinzierl 25 Jun '01

25 Jun '01

Hi Christian, thanks for your prompt answer from last Friday. Unfortunately I have another little problem: The following lines symbol eps("eps"); idx a(symbol("a"),8) ,b(symbol("b"),8), c(symbol("c"),8),d(symbol("d"),8); ex g = (1+eps*color_T(a)+pow(eps,2)*color_T(b))*(1-eps*color_T(c)+pow(eps,2)*color_T(d)); cout << expand(g) << endl; prints out eps^4*(T.b*T.d)+(T.a*T.d)*eps^3-eps^3*(T.b*T.c)-eps^2*(T.a*T.c) e.g. the terms which would have a "1" from either one of the two factors do not show up. Stefan

2 1

Class function revisited: IMHO we are badly confused about two concepts here
by Richard B. Kreckel 24 Jun '01

24 Jun '01

Dear all, In the meeting last friday I was announcing that we could easily have functions generated on the fly (as demanded by some people for doing clever tricks with manual cancellations of divergenct subterms). The issues involved were partly those raised by Roland Richter in <http://www.ginac.de/lists/ginac-list/msg00073.html>. For those that were at the meeting: scratch my claim that it could easily be done. The idea was this: Have a functor class with an overloaded operator() to return the corresponding object of class GiNaC::function. There would have to be a number of such functors, all derived from a base class, say `fncall', with the proper argument number, basically: class fncall {}; class fncall_1 : public fncall { public: const function operator()(const ex & x1) const { return function(index, x1); } private: unsigned index; }; Remember, that objects of class function (we could call them pseudofunctions) are distinguised by the sequence of arguments they hold and their serial number. All we *want* is a clean way of writing `sin(x)', `x' being an arbitrary `ex'. Right now, this is being done by declaring a global function with the right function name: const function sin(const ex & x) { return function(index, x); } This is just a sort of entrance into the GiNaC pseudofunctions. The functor per se ideally suited to be another such entrance. Pseudofunctions are registered at program startup time. This is when their name, eval function, diff function etc. are set up in a static std::vector<GiNaC::function_options>, subscripted by a plain unsigned which happens to correspond exactly to the index. In order to do this dynamically in a clean way, we would really have to abandon this static vector and instead set the data up in a std::map<unsigned, GiNaC::function_options>. Note that lookup-time in such a structure is not constant but rather logarithmic, however with a rather high offset penalty (since internally a map is a RB-tree which has left and right node pointer and an additional color state). It can still be done without any visible impact on efficiency. So, the new gateway into the pseudofunctions would defined as such: const fncall_1 sin = fncall_1(function::register_new(...... )); which still does not look very much different from the setup macro we use now. We can then still write sin(x), but now fncall_1::operator()(const ex &) is being called. It worked okay until I tried to roll this code in, when an old friend problem reappeared: The conflict of above object with this function: const numeric sin(const numeric & x); The most obvious solution out of this would be to remove these and instead add an const numeric operator()(const numeric &); to our fncall_1 class. However, the class cannot know which arithmetic function the object `sin' is supposed to call! We would have to set up the arithmetic function at construction of the `fncall' object. It could be done with passing a pointer to such a function. That pointer would then have to be stored twice: Once in the pseudofunction object corresponding to `sin' as its `evalf_funcp' (because class function can never call the object's `operator()(const numeric &)' -- the class function cannot know about it's programmatric entrance `sin'. And once again in the functor object `sin', so that the operator looks something like this: const numeric operatir()(const numeric &x) { if (arithmetic_funcp!=0) return arithmetic_funcp(x); throw (std::runtime_error("buaaaaaaahhhh")); } I hope everyone agrees that this is just crap. The problem is that the class doesn't know exactly what the object is supposed to do. So, alternatively, we could move that information directly inside the class by declaring one entrance class per entrance object, as such: class fncall_sin : public fncall { public: const function operator()(const ex & x) const { return function(index, x); } const function operator()(const numeric & x) const { return _numeric_sin(x); } private: unsigned index; }; In order to make this really sematically reasonable, however, fncall_sin would have to be a singleton class. Ugh! The way people define their own classes also becomes quite messy. So this isn't good either. The basic problem is always that we are mixing functions and pseudofunctions (objects of class function) in a non-orthogonal way. We could choose to disentangle the pseudofunctions from the arithmetic functions. There are really two different concepts here: Once, the symbolic pseudofunctions that may eventually `.hold()' and second the ones that are supposed to be doing something straightforwad, like mapping from numeric to numeric. We could wrap the latter ones into a namespace `arithmetic' sitting inside the overall namespace `GiNaC' and disambiguate the calls by using declarations. All functions which could ever make sense to be `.hold()' should be handled like this. This may include real(numeric) and imag(numeric) though they do not (yet?) have a corresponding real(ex) and imag(ex) but it would not include gcd(numeric, numeric) since that will never by treated as a symbolic function. I strongly invite you to look at the declarations in <ginac/numeric.h>: It seems to me like there is a very clear cut between normal functions and such functions that may eventually lead to collisions with pseudofunctions! This seems to work so far and I really start to like the idea to some extent. However, there this is still not entirely satisfactory. There are two problems here, one is a permanent one, another one is a temporary one. First the temporary one: #include <ginac/ginac.h> using namespace std; using namespace GiNaC; int main(void) { symbol x("x"); cout << sin(x) << endl; return 0; } Alas, we cannot do this yet. It breaks GCC-2.95.2 which treats `sin', `cos', etc. as mysterious internal entities: <internal>:6: first declared as `double sin (double)' here GiNaC/ginac/inifcns.h:41: also declared as `const GiNaC::fncall_1 GiNaC::sin' here The three-times-cursed GCC-2.96 is affected as well, GCC-3.0 and SGI's compiler on IRIX (which I love!) handle this one correct. Now the permanent problem: #include <cmath> using namespace std; #include <ginac/ginac.h> using namespace GiNaC; int main(void) { symbol x("x"); cout << sin(x) << endl; return 0; } This will always leave us with ambiguous usages of `sin' because the object clashes with the function definition in <cmath>. It will, of course, also also clash if a using directive for GiNaC::arithmetic is specified. This can never work well with using directives, only with using declarations like using GiNaC::sin; by the language rules. To summarize: In my opinion, the whole confusion is caused by the fact that we hazardously mix functions with our concept of pseudofunctions. As long as we do not steer clear of the potential clashes triggered by this, we are going to have trouble. We should really start thinking about these two as totally different entities. Functions are well suited for arithmetic mappings, functors are excellently suited as entrances to our pseudofunctions, making them more flexible. But we must not mix these concepts and the language forces us to not mix their names. In the long run, we could consider making all entrances to pseudofunctions uppercase, thus writing Sin(x) to distinguish between these two concepts, but that will require some discussion. [Remember that GiNaC is Not a CAS and the wish to write sin(1.2) to return 0.932 and sin(x) to return sin(x) is conventional in CAS but we should be allowed to raise the question if such a wish can really be justified as orthogonal to system design.] Okay, and if anybody has another suggestion or a comment or a wish, I'ld very much like to hear about it. Cheers -richy. -- Richard Kreckel <Richard.Kreckel(a)Uni-Mainz.DE> <http://wwwthep.physik.uni-mainz.de/~kreckel/>

1 0

Series expansion
by Stefan Weinzierl 22 Jun '01

22 Jun '01

Gentlemen, what's wrong with the following code in GiNaC 0.8.3: int main() { using namespace GiNaC; varidx mu(symbol("mu"),4); symbol eps("eps"); ex g = 1 + eps;; cout << g.series(eps==0,5) << endl; ex h = 1 + eps*dirac_gamma(mu); cout << h.series(eps==0,5) << endl; return 0; } The program crashes when it tries to expand h. Is the series member function actually defined somewhere for an object like dirac_gamma ? Stefan

2 1

Re: GiNaC/ginac symmetry.cpp symmetry.h
by Richard B. Kreckel 19 Jun '01

19 Jun '01

> Update of /home/cvs/GiNaC/ginac > > Added Files: > symmetry.cpp symmetry.h > Log Message: > introduced new class for constructing symmetry tree definitions This patch entirely breaks ginaccint! An analysis shows that along with a funny new bug it triggers four long-standing, many times reported and never truly fixed problems in Cint: 1) failure to recognize `unsigned' as `unsigned int', 2) occassional ommission of namespace qualifiers in generated G__cpp_foobar.C, 3) the whole std-container<..., malloc_alloc> disaster and 4) not standard-conforming *ancient* HP-derived STL. (*) The problem was isolated and reported but I don't hold my breath on this. I wonder how the Cern folks can be so proud of this product and I am now quite happy that we made the decision to separate ginaccint out of GiNaC. It only holds up development. I can hear Fermilab C++-hocho Walter Brown's upset voice: "If you have something that's broken, you either fix it or you throw it away!". Happy hacking -richy. (*) As an aside, I am under the impression that you can easily detect HP-derived headers on a compiler by triggering this bug: #include <list.h> struct foo { list<foo> children; }; Incidentally, Micro$oft VC++-6.0 doesn't eat it for the same reason the HP-STL doesn't eat it. It's amazing how many compilers barf at this seemingly innocent piece of code and when you look at the list header you almost certainly find that it was forked from STL before it's development went over to SGI. -- Richard Kreckel <Richard.Kreckel(a)Uni-Mainz.DE> <http://wwwthep.physik.uni-mainz.de/~kreckel/>

2 2

Pattern matching in GiNaC CVS
by Christian Bauer 19 Jun '01

19 Jun '01

Hi! I have committed my first attempt at implementing pattern matching facilities in GiNaC to the CVS now. It consists of two new things: - a wildcard class - a match() member function Wildcards have an unsigned label to allow having multiple different wildcards in one pattern. They are constructed with "wild(label)" and denoted "$0", "$1", "$2" etc. in the output and in ginsh. The match() function checks whether an expression matches a given pattern and if so, fills a list with relations of the form "$0 == foo", "$1 == bar", etc. to show the subexpressions matched by the wildcards. In ginsh, match() returns FAIL if there's no match, and the relation list otherwise. The subs() function has been modified to allow wildcards in the patterns and in the replacement expressions. Likewise, has() also understands wildcards. Some examples in ginsh to show how it works, and to show that it is not really intelligent (it's better than nothing, though): > match(a^b,$1^$2); [$1==a,$2==b] > match(a^b,$1^$1); FAIL > match(a^a,$1^$1); [$1==a] > match(a^a,$1^$2); [$1==a,$2==a] > match((a+b)*(a+c),($1+b)*($1+c)); [$1==a] > match((a+b)*(a+c),(a+$1)*(a+$2)); [$1==c,$2==b] (Unpredictable. The result might also be [$1==c,$2==b].) > match((a+b)*(a+c),($1+b)*($1+d)); FAIL > match((a+b)*(a+c),($1+a)*($1+c)); FAIL > match((a+b)*(a+c),($1+$2)*($1+$3)); FAIL (The result is undefined. Here, "$1+$2" matches "a+b" with $1==b,$2==a and the second factor can no longer be matched. Such thing may or may not work, depending on the sort order.) > match(2*(x+y)+2*z-2,2*$1+$2); [$1==z,$2==-2+2*x+2*y] (This is also ambiguous. Another possibility would be [$1=x+y,$2=2*z-2]. It also shows that it is a syntactic match.) > match(a+b+c,a+$1); [$1==c+b] > match(a+b+c,b+$1); [$1==c+a] > match(a+b+c,c+$1); [$1==a+b] > match(a+b+c,a+c+$1); [$1==b] (A single wildcard in a sum or product gobbles up all remaining unmatched terms.) > match(a+b+c,a+$1+$2); [$2==b,$1==c] (Pure coincidence. It may also have happened that one of the wildcards eats the "a", causing the match to fail. But matching with "a+$1" as above is 100% reliable.) > subs(a^2+b^2+c^2,$1^2==$1^4); b^4+a^4+c^4 > subs(a^3+b^3+c^3,$1^2==$1^4); b^3+c^3+a^3 (It's still not an algebraic substitution...) > match(a*b^2,a*b*$1); FAIL (...let alone an algebraic match.) > match(a*b^2,a^$1*b^$2); FAIL (Likewise. The matching is purely syntactic.) > subs(sin(x+y)^2+cos(x+y)^2, cos($1)^2==1-sin($1)^2); 1 (Straightforward now.) > subs(a+b+c,a+b==e); c+a+b (Once again, we still don't do an algebraic substitution.) > subs(a+b+c,a+b+$1==e+$1); c+e (But this works.) > subs(a+b,$1+a==2*$1); 2*b > subs(a+b,$1+b==2*$1); 2*a > subs(a+b,$1+$2==$1*$1); b^2 (Another random result, a^2 would also be possible.) > subs(a+b,$1+$2==$1*$2); a*b > subs(a+b+c,$1+$2==$1*$2); c*(a+b) (As you probably would have guessed by now, it might also have been any of the two other permutations of a, b and c.) > subs(a+b+c,$1+$2+$3==$1*$2*$3); c*a*b (This works again.) > subs(sin(1+sin(x)),sin($1)==cos($1)); cos(1+cos(x)) (This is the way it works now...) > has(a^2+b^2+c^2,$1^2); 1 > has(a^2+b^2+c^2,$1^3); 0 > has(a^2+b^2+c^2,$1+$2); 1 Indices are currently matched by index value only. This will change. You are encouraged to try this for yourself and find bugs. Any suggestions are welcome as long as they are easy to implement. :^) Bye, Christian -- / Coding on PowerPC and proud of it \/ http://www.uni-mainz.de/~bauec002/

3 8

Macros are evil (tm)
by Richard B. Kreckel 15 Jun '01

15 Jun '01

Hi all, This is gonna be long. If you just want to know what you soon need to do to your source files and are not interested in why, please jump to the end of this email. The usual way of implementing polymorphic methods accepting ex arguments in GiNaC involves checking the arguments for their types. This results in switch-like statements of the form ex mul::somemethod(const ex & other) { if (is_ex_of_type(add)) { // do this... } else if (is_ex_of_type(mul)) { // do that... } else { // do something else... } } Okay, language lawyers (*) usually construe those switch statements as bad. But since C++ does not have generic multiple dispatch the usual answer is that they offer some variation of home-grown double dispatch, maybe by bloating the add and mul classes with overloaded methods like this: class basic { // ... virtual ex somemethod(const add & other); virtual ex somemethod(const mul & other); ex somemethod(const ex & other); }; // same for add and mul mul::somemethod(const ex & other) { return ex.bp.somemethod(*this); } So the proper implementation is called by two subsequent lookups in the virtual function table. Nothing prohibits us from doing it this way in GiNaC but for the objects we are dealing with in a CAS so far we have always chosen the switch way of implementing and found this much more accessible and readable. Just consider the various print functions that recently were changed to accept an object of type print_context or derived to format the output properly. The different ways need to be implemented somewhere and why not deal with all of them in foo::print(). What is this guy ranting about?!? Who cares? Cool, if you don't care. The only thing that really bothered me so far is the use of macros at this place. The definition of is_of_type(obj, type) by a macro 1) lives outside the namespace and may collide some time, 2) accepts all kind of funny arguments with barely and possibility for compile-time checking, 3) does not allow overloading, so there is an is_of_type and another is_ex_of_type with the same semantics and 4) is generally crap with respect to readabilty and makes steam come out of the ears of language lawyers. A better approach would be to use a template here. We could write is_a<numeric>(foo) where foo is either something derived from basic or an ex and it will produce the expected outcome. There will of course also be an is_exactly_a<tensor>(bar) matching only tensors and not classes derived from tensor. We can implement it in exactly the same way as the macros were implmented, for instance like this: template <class T> inline bool is_a(const basic & obj) { return dynamic_cast<const T *>(&obj)!=0; } template <class T> inline bool is_a(const ex & obj) { return is_a<T>(*obj.bp); } The only cause for concern is template <class T> inline bool is_exactly_a(const class basic & obj) { const T foo; return foo.tinfo()==obj.tinfo(); } because it has to allocate a temporary. But this is not a big deal, since we are allowed to specify template specializations, for instance in file add.h we would write down template<> inline bool is_exactly_a<add>(const basic & obj) { return obj.tinfo()==TINFO_add; } giving us all the performance back. We all know that "An Inline Function is As Fast As a Macro" (an actual section title in GCC's info page). So we should do it. Now. Surprise! The inliner in GCC-2.95 does some very poor job at flow analysis inside if statements when inlined functions return some boolean (or integer, no matter). Consider this code: struct ABC { virtual ~ABC() {} }; struct A : public ABC {}; template <class T> inline bool is_a<T>(const ABC & obj) { return (dynamic_cast<const T *>(&obj)!=0); } #define is_of_type(OBJ,TYPE) \ (dynamic_cast<const TYPE *>(&OBJ)!=0) #ifdef USE_MACRO int test(const ABC & e) { if (is_of_type(e,A)) return 1; return 0; } #else int test(const ABC & e) { if (is_a<A>(e)) return 1; return 0; } #endif The compiler generates in the case where USE_MACRO is defined at preprocessing level: 00000000 <test(ABC const &)>: 0: 55 push %ebp 1: 89 e5 mov %esp,%ebp 3: 83 ec 08 sub $0x8,%esp 6: 8b 45 08 mov 0x8(%ebp),%eax 9: 85 c0 test %eax,%eax b: 74 28 je 35 <test(ABC const &)+0x35> d: 83 c4 f8 add $0xfffffff8,%esp 10: 50 push %eax 11: 68 00 00 00 00 push $0x0 12: R_386_32 ABC type_info function 16: 8b 10 mov (%eax),%edx 18: 03 02 add (%edx),%eax 1a: 50 push %eax 1b: 6a 01 push $0x1 1d: 68 00 00 00 00 push $0x0 1e: R_386_32 A type_info function 22: ff 72 04 pushl 0x4(%edx) 25: e8 fc ff ff ff call 26 <test(ABC const &)+0x26> 26: R_386_PC32 __dynamic_cast 2a: 85 c0 test %eax,%eax 2c: 74 07 je 35 <test(ABC const &)+0x35> 2e: b8 01 00 00 00 mov $0x1,%eax 33: eb 02 jmp 37 <test(ABC const &)+0x37> 35: 31 c0 xor %eax,%eax 37: c9 leave 38: c3 ret while in the inline case it generates this entirely contorted code: 00000000 <test(ABC const &)>: 0: 55 push %ebp 1: 89 e5 mov %esp,%ebp 3: 83 ec 08 sub $0x8,%esp 6: 8b 45 08 mov 0x8(%ebp),%eax 9: 85 c0 test %eax,%eax b: 74 24 je 31 <test(ABC const &)+0x31> d: 83 c4 f8 add $0xfffffff8,%esp 10: 50 push %eax 11: 68 00 00 00 00 push $0x0 12: R_386_32 ABC type_info function 16: 8b 10 mov (%eax),%edx 18: 03 02 add (%edx),%eax 1a: 50 push %eax 1b: 6a 01 push $0x1 1d: 68 00 00 00 00 push $0x0 1e: R_386_32 A type_info function 22: ff 72 04 pushl 0x4(%edx) 25: e8 fc ff ff ff call 26 <test(ABC const &)+0x26> 26: R_386_PC32 __dynamic_cast 2a: 85 c0 test %eax,%eax 2c: 0f 95 c0 setne %al 2f: eb 02 jmp 33 <test(ABC const &)+0x33> 31: b0 00 mov $0x0,%al 33: 84 c0 test %al,%al 35: 75 09 jne 40 <test(ABC const &)+0x40> 37: 31 c0 xor %eax,%eax 39: eb 0a jmp 45 <test(ABC const &)+0x45> 3b: 90 nop 3c: 8d 74 26 00 lea 0x0(%esi,1),%esi 40: b8 01 00 00 00 mov $0x1,%eax 45: c9 leave 46: c3 ret This turned out to be the performance hammer of about 25% that I saw when I first tried substituting the macros by templates. And it also turns out that the new GCC-3.0 produces better and roughly equivalent code in both cases, the templated one being even slightly superior as far as I can see. So, this is what we'll do: (Remember that GCC-3.0 is going to be released today.) In all cases the old macros will be supplemented by the template functions and specializations for is_exactly_a<>() for all critical cases. Inside the library we'll stick with the macros for some while in the time critical parts until GCC-3.0 catches on. (BTW: GCC-3.0 produces code that is roughly 10%-30% faster at the GiNaC benchmarks. Rejoice and upgrade!) Eventually these macros will be entirely phased out. I just finished checking the changes in to CVS. In my applications I used a Perl script to convert from the macros to the new inline template functions which is supplied herewith WITHOUT ANY WARRANTY WHATSOEVER. It actually works for converting the GiNaC library but you should of course make a backup first. Once GiNaC 0.9.1 rolls out (or if you are running from CVS) please apply this converter to your source files. ----------8<------------------8<---------------------8<----------------- #! /usr/bin/perl -w my $file; my $tmpfile; if ($file = $ARGV[0]) { print STDERR "replacing in file $file\n"; $tmpfile = "tmp${file}tmp"; } else { print STDERR "*** no file given\n"; exit; } open (CPPFILE, $file) or die "Can't open source file: $!\n"; open (TMPFILE, "> $tmpfile") or die "Can't open temporary file: $!\n"; while ($_ = <CPPFILE>) { # is_exactly_of_type(foo,bar) -> is_exactly_a<bar>(foo) s/is_exactly_of_type$([\*\.a-zA-Z_0-9\($\[\]\+\-\>]+)[, ]+([a-zA-Z_0-9]+)\)/is_exactly_a\<$2\>$$1$/g; # is_ex_exactly_of_type(foo,bar) -> is_exactly_a<bar>(foo) s/is_ex_exactly_of_type$([\*\.a-zA-Z_0-9\($\[\]\+\-\>]+)[, ]+([a-zA-Z_0-9]+)\)/is_exactly_a\<$2\>$$1$/g; # is_of_type(foo,bar) -> is_a<bar>(foo) s/is_of_type$([\*\.a-zA-Z_0-9\($\[\]\+\-\>]+)[, ]+([a-zA-Z_0-9]+)\)/is_a\<$2\>$$1$/g; # is_ex_of_type(foo,bar) -> is_a<bar>(foo) s/is_ex_of_type$([\*\.a-zA-Z_0-9\($\[\]\+\-\>]+)[, ]+([a-zA-Z_0-9]+)\)/is_a\<$2\>$$1$/g; print TMPFILE "$_"; } close CPPFILE; close TMPFILE; `mv $tmpfile $file`; ---------->8------------------>8--------------------->8----------------- Regards -richy. (*) "The first thing we do, let's kill all the language lawyers." Henry VI, part II, taken from TC++PL-3, chapt 2. -- Richard Kreckel <Richard.Kreckel(a)Uni-Mainz.DE> <http://wwwthep.physik.uni-mainz.de/~kreckel/>

1 0

Release 0.9.0 just hit the web
by Richard B. Kreckel 07 Jun '01

07 Jun '01

Go, grab your copy now, as long as supply lasts! Don't let others snatch away the few copies left at <ftp://ftpthep.physik.uni-mainz.de/pub/GiNaC/>! Hurry!!! Pronto!! ¡Rapido! Los! The NEWS file says: * In the output and in ginsh, lists are now delimited by { } braces, and matrices are delimited by single [ ] brackets. * simplify_indexed() renames dummy indices so, e.g., "a.i*a.i+a.j*a.j" gets simplified to "2*a.i*a.i" (or "2*a.j*a.j"). * New functions/methods: - canonicalize_clifford() (helpful when comparing expressions containing Dirac matrices) - symmetrize() and antisymmetrize() - numer_denom() (return numerator and denominator in one call) - map() (apply function to subexpressions) - evalm() (evaluate sums, products and integer powers of matrices) * Added a new function match() for performing pattern matching. subs() and has() also accept patterns as arguments. A pattern can be any expression, optionally containing wildcard objects. These are constructed with the call "wild(<unsigned>)" and are denoted as "$0", "$1" etc. in the output and in ginsh. * Positive integer powers of non-commutative expressions (except matrices) are automatically expanded. * Removed cint subdirectory, ginaccint is a separate package now due to packaging considerations. * Several little bugfixes. * More exclamation marks than ever in the announcement.

1 0

Two little announcements
by Richard B. Kreckel 01 Jun '01

01 Jun '01

Hi, First, I'ld like to point out that yesterday we have unleashed CLN-1.1.1 onto the world. No big changes, but a couple of important bugs were fixed that do affect GiNaC on non-Intel hardware and on the upcoming GCC-3.0. Oh, thank you very much for the applause! ;-) Second, I would like to move the ./cint subdirectory out of GiNaC. The reason is that Cint is too disappointing right now for GiNaC-cint to be really useful. I have here a nice list of open bugs that won't go away in the near future and that make using it a pain in the neck. The main problem is, however, Cint's portability: it wants to eat your harddisk on Linux/m68k, it has weird linking bugs on Linux/arm and despite my efforts to point out to the ROOT folks at Cern that they will be in a hell of a trouble soon if they don't work on the GCC-3.0 port nothing really happens on this front. (Try compiling Cint on GCC-3.0: it fails in a very spectacular way but doesn't even seem to notice so!) The real problem is of course less the new compiler bug the up-to-date STL. Cint's approach to STL based on ancient sources by HP definitely won't work much longer. Bottom line: the intersection of the set of platforms supported by CLN and GiNaC on the one side and of Cint on the other seems to be quite small. This makes the current situation a headache for distribution packagers: if you configure --with-cint you must exactly know your platform, specifying "Architecture: any" would otherwise work fine for both GiNaC and CLN. Instead, starting with GiNaC-0.9.0 we'll have a separate package GiNaC-cint that will be kicked along and updated when need should arise. Packagers can then throw this at their build-daemons and whatever comes out will probably `work', but that won't have any side-effects on the building of the GiNaC library. Sex, drugs and Unix -richy. -- Richard Kreckel <Richard.Kreckel(a)Uni-Mainz.DE> <http://wwwthep.physik.uni-mainz.de/~kreckel/>

1 0

problem with print_csrc and mul
by Hugo LECLERC 24 May '01

24 May '01

Dear GiNaC developpers, with GiNaC V0.8.2 and V0.8.3, there is a problem when one wants to print a formula with print_csrc_context and a mul into: #include <iostream.h> #include <ginac/ginac.h> using namespace GiNaC; int main(int argc, char *argv[]) { symbol x("x"),y("y"); ex expr=x*y; expr.print(print_csrc_double(cout)); return EXIT_SUCCESS; } gives : (y*x ( and not y*x ) It becomes better when in mul.cpp, line 139, we had if (precedence <= level) before c.s << "("; That's all. Best regards and many thanks for your work! PS: I'm actually looking for how to convert GiNaC list of expressions in optimized C code (like "convert to C" in mathlab). I've already begun and my question is : is there anything done in this domain? - Hugo LECLERC L.M.A.R.C. Laboratory of Applied Mechanics R. Chaléat UMR CNRS 6604, UFR Sciences et Techniques 24, chemin de l'Epitaphe 25000 BESANCON - FRANCE Tel : +33 (0)3 81 66 60 11 ou +33 (0)3 81 66 67 21 Fax : +33 (0)3 81 66 67 00

2 1

Small bug in power::print_latex
by Stefan Weinzierl 24 May '01

24 May '01

Hi, if I do symbol x("x"); ex f=pow(x,10); f.print(print_latex(cout)); I get x^10 which latex prints out roughly as 1 x 0 Putting some curly braces around the exponent should fix the problem, e.g. if one replaces line 200 in power.cpp (GiNaC 0.8.3) exponent.print(x,precedence) by something like if (is_of_type(c,print_latex)) c.s<<"{"; exponent.print(x,precedence) if (is_of_type(c,print_latex)) c.s<<"}"; Best wishes, Stefan

1 0