- GiNaC-list - ginac.de

Differentiating and substituting series
by Alexander Heide 07 Aug '02

07 Aug '02

Hello, I've tried to replicate calculations involving series expansions that I did with Mathematica. Here are some comments: The following program #include <iostream> #include <ginac/ginac.h> using namespace std; using namespace GiNaC; int main() { symbol x("x"), a("a"); cout << (1 + a*x + Order(pow(x, 2))).series(x == 0, 2).diff(a) << endl; cout << (1 + Order(x) + Order(pow(x,2))).series(x == 0, 2) << endl; ex series1 = (a + Order(pow(x,2))).series(x == 0, 2); ex series2 = (1 + Order(x)).series(x == 0, 1); cout << series1.subs(a == series2) << endl; return 0; } prints out: 1+(a)*x+Order(x^2) 1+Order(x) (1+Order(x))+Order(x^2) I would like to obtain 'x+Order(x^2)' in the first line. That is what Mathematica does when differentiating a series with respect to some parameter. The second line is exactly what I expect but the third line should be the same as the second. Mathematica behaves in the same way as GiNaC so that I had to write an extra function 'SeriesUnnest' that would expand the third expression into the second. Unfortunatly I don't have time and skills to make an suggestion how to hande this situation in GiNaC... Greetings, Alexander Heide

2 1

possible improvements
by Chris Dams 05 Aug '02

05 Aug '02

Hello everybody, I have been thinking about some improvements for GiNaC that I might want to see implemented and that I might even have a try at myself. No guarantees that I will do anything, but I just might if I find some time. Before doing anyting, however, I would like to know what GiNaCs authors/maintainers think of my "improvements". Which of them would they include in the library, if they were implemented? Well, here they are: (1) Sometimes I find that GiNaC expressions can become so large that I run out of memory. Having a swapping GiNaC running on a computer is terrible. Technically speaking it does not crash the computer, however practically speaking, it is as good as a crash. Typically this happens for expressions that are large sums of which most terms are multiplications. Wouldn't it be nice to have a new class "largeadd" that stores its terms in a file rather then in memory. (If terms are products these would be saved in the file too, but the factors themselves would probably be kept in memory.) For the user, the most sensible way of manipulating a largeadd would be to have a map_function acting on it, performing various tasks at once, so that the terms in the largeadd do not need to be retrieved and stored too often. (2) Introduce a new expand_option that prevents GiNaC from expanding inside powers with exponents that aren't positive integers. For example, a user might want to have (a+b)^2*(1+(x+y)^2)^(-1) expanded into a^2*(1+(x+y)^2)^(-1) + 2*a*b*(1+(x+y)^2)^(-1) + b^2*(1+(x+y)^2)^(-1) instead of having the denominator expanded too. (3) Using so-called schoonschip-notation for indexed objects. The idea is that if an object with one index is contracted with another object, the base-expresion of the one-index-object is put at the position where the index occurs that it is contracted with. Example: A.mu~nu*p~mu --> A(p,~nu) Note that this would require indexed objects to be able to take non-idx expressions as arguments. Also one would want to introduce the notion of an inner product, leading to the automatic simplification rule: p.mu*q~mu --> inp(p,q). The point is that this often greatly reduces the amount of indices thereby allowing further simplifications. Also one no longer needs to call simplify_indexed, which, at times, is a somewhat expensive function. (4) Haven't really looked at this terribly carefully yet, but I suppose the function dirac_trace can be made much more efficient. The idea of expanding gamma5 into eps(i1,i2,i3,i4)*gamma(i1)*...*gamma(i4) (which happens inside the function dirac_trace) really looks like a winner for the award for inefficient algorithms. Also, there could be made a function that takes the trace of all spin-lines at the same time, using the Chisholm identity whenever possible. I would guess that this also makes things much faster. Greetings, Chris Dams

3 5

Q: What comes after nine?
by Richard B. Kreckel 24 Jul '02

24 Jul '02

A: ten! Seriously, what else did you expect? So, here goes GiNaC version 1.0.10... (*) ...incorporating bug fixes only, at least unless you haven't been using undocumented internal features. (Hi Markus!) Happy compiling -richy. (*) Yep, it's Debian/woody approved! -- Richard B. Kreckel <Richard.Kreckel(a)Uni-Mainz.DE> <http://wwwthep.physik.uni-mainz.de/~kreckel/>

1 0

problem with anti-symmetric functions and tensors --> solved?
by Chris Dams 22 Jul '02

22 Jul '02

Hello everybody, I found that the program #include<iostream> #include<ginac/ginac.h> using namespace std; using namespace GiNaC; DECLARE_FUNCTION_2P(f) ex f_eval(const ex&x,const ex&y) { return f(x,y).hold(); } REGISTER_FUNCTION(f,eval_func(f_eval).set_symmetry(sy_anti(0,1))); int main() { cout << f(0,1) << endl; cout << f(1,0) << endl; cout << f(0,0) << endl; } which defines an anti-symmetric function and then tries it with some values, gives as output f(0,1) -f(0,1) f(0,0) The last result is not as expected, since an anti-symmetric function is equal to zero when both arguments are the same. I found that this happens because in the function *canonicalize* in the file symmetry.cpp the value of *sign* (which, as expected, turns out to be zero if the two arguments are the same) is ignored if the variable *something_changed* is *false* (which is the case in the third example because the two arguments are the same and thus already sorted in ascending order). The problem is solved by adding after the line (which appears in the function *canonicalize*) sign *= permutation_sign(first, last, sy_is_less(v), sy_swap(v,something_changed)); the new line if(!sign)return 0; After this my testprogram gives the result f(0,1) -f(0,1) 0 which is what I would have expected in the first place. Note that this also fixes the same problem for anti-symmetric tensors. Greetings, Chris Dams

2 1

'make check' fails!
by William Woods 18 Jul '02

18 Jul '02

Hi, I'm compiling GiNaC 1.0.9 with gcc3.1, and everything seems to go ok, no error messages from 'make'. But 'make check' - which also compiles fine - fails on all three tests. CLN tests ran fine. Any ideas? Thanks, Will make[2]: Entering directory `/home/will/tmp/GiNaC-1.0.9/check' GiNaC will now take an exam with specific input (like a pupils' exam): examining several historic failures just out of paranoia.............. passed examining consistency of numeric types....../run_exams: line 3: 27225 Aborted ./exams 2>exams.out cmp: EOF on exams.out FAIL: run_exams GiNaC will now run through some rather costly random consistency checks: checking consistency of numeric types.. passed checking consistency of symbolic functions.... passed checking symbolic matrix manipulations..... passed checking linear solve....../run_checks: line 3: 27249 Aborted ./checks 2>checks.out cmp: EOF on checks.out FAIL: run_checks GiNaC will now run through some basic timings: timing commutative expansion and substitution.... passed size: 25 50 100 200 time/s: 0.01 0.04 0.19 0.88 timing Laurent series expansion of Gamma function./run_times: line 3: 27277 Aborted ./times 2>times.out cmp: EOF on times.out FAIL: run_times =================== 3 of 3 tests failed =================== make[2]: *** [check-TESTS] Error 1 make[2]: Leaving directory `/home/will/tmp/GiNaC-1.0.9/check' make[1]: *** [check-am] Error 2 make[1]: Leaving directory `/home/will/tmp/GiNaC-1.0.9/check' make: *** [check-recursive] Error 1 __________________________________________________ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com

2 8

segmentation fault in simplify_indexed --> solved?
by Chris Dams 25 Jun '02

25 Jun '02

Hello everybody, I think I have solved an error in GiNaC that sometimes (only in special circumstances) causes a segmentation fault when *simplify_indexed* is called. The problem occurs when the function *diracgamma::contract_with* is sometimes called with the arguments *self* and *other* pointing to two gamma matrices of different representation label. In that case it can happen that there is a gamma5 in between and that the function *base_and_index* is called with the gamma5 in its first argument. This is wrong because base_and_index tries to look at operand number 1, which does not exist for a gamma5. This then may cause a segmentation fault. It never happens for gamma matrices of the same rep. label because the gamma5 has been permuted out of the way then. I found that the segmentation fault dissapears when inside the first *if* in *diracgamma::contract_with* I add a test that checks if rep. labels are equal (the contract-gamma-matrices algorithms there, do not seem to make much sense if rep. lables are different anyway). After my addition the code looks like if (is_a<clifford>(*other)) { unsigned char rl2 =ex_to<clifford>(*other).get_representation_label(); if(rl!=rl2) return false; ex dim = ex_to<idx>(self->op(1)).get_dim(); where the first and last line are yours and the three in the middle are mine. (BTW this is GiNaC-1.0.8). Greetings, Chris

2 1

GiNaC 1.0.9 now available (AKA Episode I - The Indexed Menace)
by Christian Bauer 11 Jun '02

11 Jun '02

FADE IN EXT. UNIVERSITY BUILDING - EVENING It is a quiet, hot summer evening. The setting sun casts its last rays on the Physics Department building, giving the stone walls a wonderful warm golden glow. The only sounds that are heard are the raspy cries of a black swarm of ravens that circles in the sky. Two cyclists ride down the street in front of the building. CUT TO INT. UNIVERSITY BUILDING, OFFICE - CONTINUOUS There are numerous desks and computers in this small, dimly lit room in the fifth floor of the Physics Department building. The walls are lined with large cupboards, science fiction posters, GiNaC logo designs and hardcopies of 'Dilbert' cartoons. Quiet piano music fills the air. Only two people are still working at this time of day. One, RICHY K. is sitting in a corner of the room, close to the window, with his bare feet laid on top of the desk and a notebook computer in his lap. The other, CHRISTIAN B., is busy studying eBay article listings on one of two monitors on his desk in the middle of the room. RICHY K. presses a few keys on his notebook and takes a sip from a cocktail glass. Then he speaks without turning his eyes away from the screen. RICHY K. There's a tarball at the usual place now. CHRISTIAN B. Cool... CHRISTIAN B. clicks on the 'shell' icon on his computer's desktop and starts typing commands. CHRISTIAN B. So we're going to release today? RICHY K. Yup. He brings up a Mozilla window displaying the Slashdot front page on his notebook. CHRISTIAN B. Did you put the champagne in the fridge? RICHY K. Pardon? CHRISTIAN B. (louder) Did you put the champagne in the fridge? RICHY K. We don't have any champagne. CHRISTIAN B. How can we release without champagne? RICHY K. Only drinking all the time... CHRISTIAN B. types some more commands. CHRISTIAN B. Is this 1.1.0? RICHY K. Nope, 1.0.9. CHRISTIAN B. Will we have champagne when we get to 1.1.0? RICHY K. Maybe... CHRISTIAN B. slams down the 'Return' key on his keyboard and leans back. Progress messages of a compiler run start scrolling down the screen. He returns his attention to the eBay listings on the second monitor. CHRISTIAN B. They're selling an eight-CPU Origin for 180,000 here... RICHY K. Cool. Tell Hubert to buy it. CHRISTIAN B. Where is Hubert, anyway? RICHY K. I don't know... RICHY K. takes another sip from his orange-red cocktail. CHRISTIAN B. glances over the compiler output but then looks back at his browser window and types in a URL. CHRISTIAN B. Did you get yesterday's User Friendly? RICHY K. What? CHRISTIAN B. (louder) Yesterday's User Friendly. Did you understand the punch line? RICHY K. Nope. CHRISTIAN B. What does that Russian sentence mean? RICHY K. Don't know. CHRISTIAN B. You ought to know. You've been in Russia. RICHY K. They all spoke English there. CHRISTIAN B. Oh. The compiler run is still in progress. CHRISTIAN B. grabs his coffee mug, slowly stands up, and walks over to the coffee machine. After filling the mug he returns to his place. CHRISTIAN B. You're already writing the announcement? RICHY K. It's your turn this time. CHRISTIAN B. No, it's not. I wrote the announcement for 1.0.8. RICHY K. No, you didn't. I did. It's your turn now. CHRISTIAN B. It's always 'my turn'. Why is it always my turn? RICHY K. It isn't. You're only trying to sneak out of having to write it. CHRISTIAN B. I'm not. He turns back to the monitors. Seeing that the compiler run has finished successfully, he continues to enter commands. CHRISTIAN B. RPM builds fine. I'll move it to the FTP server. RICHY K. Pardon? CHRISTIAN B. (louder) I will upload the RPM to the FTP server. RICHY K. Suit yourself... CHRISTIAN B. Did you tag the CVS? RICHY K. gasps with ostentation and starts pressing keys. RICHY K. Tagged. CHRISTIAN B. Nearly... CHRISTIAN B. still hacks away at his keyboard. RICHY K. Are you writing the announcement now? CHRISTIAN B. It's your turn. Besides, I can't write announcements without champagne. RICHY K. There should still be some wine in the cupboard. CHRISTIAN B. turns around to the cupboard behind him and opens the lower door. His face brightens up when he sees several bottles of red and white wine. CHRISTIAN B. (smiling) I'll write the announcement... FADE OUT

1 0

small inconsistency?
by Ben Sapp 27 May '02

27 May '02

Hi, Below I provide a small example program which I think illustrates a small inconsistency in GiNaC. The program prints out x==4 x==4 and then exits. I think that if the "==" operator were handled consistently with other operators it should print out y==4 x==4 If I change the "==" operator to "+" it behaves as I expect. Cheers, Ben. ------------------------------------------------------------- #include <ginac/ginac.h> using namespace GiNaC; int main(int argc, char *argv[]) { symbol x("x"), y("y"); // change the "==" to a "+" and it works as expected ex b = (x == 4); cout << b.subs(x == y) << std::endl; cout << b << std::endl; return 0; } -------------------------------------------------------------

2 1

Note: compilation problem / CLN / "missing libraries"
by bullet.train 27 May '02

27 May '02

Dear List, I have had a long chase trying to compile GiNaC- The problem has been trying to compile the CLN tests and libraries. The symptoms are that the CLN test break and GiNaC fails to compile- compiler g++ --version 2.96 (nasty RH version) under linux the problem is caused by the following line in cln-config libdirs=-L${exec_prefix}/lib If this is present then the compiler flags see -L/usr/local/etc/etc and then the compiler cannot find any of the usual libraries and so breaks this test and doesn't make. Commenting out this line with '#' fixes the problem. This is probably not a ginac problem- so this is for information only- SA

2 1

relational creation
by Ben Sapp 20 May '02

20 May '02

Hi, I noticed in relational.cpp there is a line like this: (Should be one line but my mailer brakes it up) ----------------------- new relational(lh.eval(level-1),rh.eval(level-1),o))->setflag(status_flags::dynallocated | status_flags::evaluated); ---------------------- The question I have is if I am creating relationals using the "new" operator do I need to call the "->setflag(status_flags::dynallocated)" function? Thanks, Ben.

2 2