- GiNaC-devel - ginac.de

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

polynomial arithmetic over ginac
by Parisse Bernard 23 May '01

23 May '01

I have now a little bit improved the package of my polynomial and rational fractions utilities over GiNaC (0.6.4) It provides now gcd normalization, factor (square-free and rational roots), partfrac & integrate (assuming factor works on the denominator), for example: integrate '1/(x^4-1)^5' returns -1155/8192*log(1+x)-1155/4096*atan(x)+1155/8192*log(-1+x)+1/2048*(-893*x-1375*x^9+1755*x^5+385*x^13)*(-1+x^4)^(-4) # Time for (integrate)0.04 You can retrieve and test it at ftp://fourier.ujf-grenoble.fr/pub/hp48/giac.tgz Bye, Bernard Parisse

4 9

Wildcards for subs()
by Christian Bauer 23 May '01

23 May '01

Hi! It has been suggested to me that it would be a desirable feature for subs() to be able to specify wildcards for indices and function arguments so you could, for example - in "sin(x-1)+sin(2*y)", substitute sin(?) by cos(?)/2 to get "cos(x-1)/2+cos(2*y)/2" - in "atan2(x+y,z^2)", substitute atan2(?1,?2) by ?2/?1 to get "z^2/(x+y)" - in "F.mu*g.nu.rho+F.nu*g.mu.rho", substitute F.? by a.?+b.? to get "(a.mu+b.mu)*g.nu.rho+(a.nu+b.nu)*g.mu.rho" This should be relatively easy to implement by extending indexed::subs() and function::subs() and adding a new "wildcard/wild" class that has an integer member to distinguish multiple wildcards. Function substitution would then go something like e.subs(atan2(wild(1), wild(2)) == wild(2)/wild(1)); and substitution of base expressions of indexed objects is similar: e.subs(indexed(wild(), mu) == indexed(wild(), mu)/2+indexed(A, mu)); Wildcards for indices are a little more involved because indices must be of class idx, so one would have to write e.subs(indexed(F, varidx(wild(), 4)) == indexed(a, varidx(wild(), 4)) + indexed(b, varidx(wild(), 4))); which is a little clumsy but has the advantage of taking index dimensions and variance into account (this can also be a disadvantage because it could only substitute F~mu, not F.mu). Any comments/suggestions? Bye, Christian -- / Coding on PowerPC and proud of it \/ http://www.uni-mainz.de/~bauec002/

3 4

bug: get_precedence() is not working
by Pearu Peterson 20 May '01

20 May '01

Hi again, The output of, for example #include <ginac/ginac.h> using namespace GiNaC; main() { symbol x("x"), y("y"); std::cout << ex_to_add(x+y).get_precedence() << std::endl; } should be 40 but I am getting 70 It seems to me that one has to define for each class, that redefines basic::precedence, also the get_precedence() function. Clearly it is not C++ way, but may be it is due to that basic::precedence is defined static. Sorry, but right now I don't have any idea how to fix it... Pearu

3 6

mul::print bug
by Pearu Peterson 16 May '01

16 May '01

Hi! It appears that in the print_csrc context of mul::print function a line if (precedence <= level) is missing just before of the line #139 in mul.cpp c.s << "("; which is causing the following incorrect result: >>> ((x+y)**(x*y)).to_csrc() pow(y+x,(y*x) for instance. Regards, Pearu

2 1

Version 0.8.3 is on the wire.
by Richard B. Kreckel 11 May '01

11 May '01

This is from the NEWS file: - color and clifford classes are functional and documented. - New "spinidx" class for dotted/undotted indices. - Predefined spinor metric tensor (created by spinor_metric()). - Symbols can have a LaTeX name, e.g. symbol s("s", "\\sigma"); - LaTeX output of indexed objects is much nicer. - Fix some build-problems (with recent libreadline). (*) - Semantics of arithmetic operators now follows the C++ rules more strictly. (*) Hi Julian! ;-) Enjoy -richy. -- Richard Kreckel <Richard.Kreckel(a)Uni-Mainz.DE> <http://wwwthep.physik.uni-mainz.de/~kreckel/>

1 0

Wishlist (relational, pseries, matrix)
by Pearu Peterson 07 May '01

07 May '01

Hi! I have been working with GiNaC's interface to Python for some time now and I have collected the following notes that I have found important in this kind of applications: 1) Having relational::get_operator() would be useful (read: necessary) for extensions that can perform symbolic operations like (a < b) && (b > a) -> a < b 2) If a,b are compatible pseries then ex(a) * ex(b) would automatically produce ex(a.mul_series(b)) The same for operations +,-,scalar_mul,scalar_div. If a,b are incompatible, then apply current behaviour (that is, do nothing). I have implemented this behaviour in the GiNaC->Python interface but it does not cover cases where multiplication is carried out inside GiNaC functions. I am thinking of applications where, for example, a matrix consists of compatible pseries and the task is to find its inverse. 3) If a,b are compatible matrices (for a given operation) then ex(a) * ex(b) -> ex(a.mul(b)) The same for operations +,-,scalar_mul,scalar_div. That's all for now. Regards, Pearu

2 2

gTybalt 0.0.4
by Stefan Weinzierl 03 May '01

03 May '01

Dear all, for those who are interested, I put a new version of gTybalt on the web. (http://www.fis.unipr.it/~stefanw/gtybalt.html) gTybalt is a small program build on top of some other packages (GiNaC, TeXmacs, Root, ...) and provides basically TeX-type fonts output for GiNaC and some basic plotting routines. The installation of the new version has become a little bit more user-friendlier, no modifications or adjustment of TeXmacs or GiNaC are needed any more. Enjoy it, Stefan

1 0