- GiNaC-list - ginac.de

Accuracy of print_csrc_double
by Pearu Peterson 23 Sep '02

23 Sep '02

Hi, Is it possible to increase the accuracy of print_csrc_double output? print_csrc_double in GiNaC-1.0.8 shows only 6 decimal digits but I would like to have at least 16 digits displayed. Is it possible? Thanks, Pearu

2 1

Documentation of prem()
by Tatiana Zolo 23 Sep '02

23 Sep '02

Dear all, the documentation about the function prem() (section 5.5.3 of GiNaC 1.0.11) says that the pseudo-remainder of 'a' and 'b' satisfies c*a = b*q + prem(a, b, x), where c = b.lcoeff(x)^(a.degree(x) - b.degree(x) + 1). I think there is maybe a mistake (probably a printing mistake), the formula should be c*a = c*b*q + prem(a, b, x), where c = b.lcoeff(x)^(a.degree(x) - b.degree(x) + 1). Regards, Tatiana Zolo

2 1

Function `lsolve()'
by Tatiana Zolo 18 Sep '02

18 Sep '02

Dear all, we need to use the function `lsolve()' that appears on page 5 of the tutorial for GiNaC 1.0.10, but not in the Concept Index. We couldn't find it elsewhere, not even in the specifications for the class matrix. We would like to know its specifications, if possible. In particular, we have linear systems whose associated matrix may have some linear dependencies. Thank you very much in advance Alessandro Zaccagnini and Tatiana Zolo

2 1

Neue Version
by Jens Vollinga 18 Sep '02

18 Sep '02

1.0.11 da ist.

1 0

gcd() and lcm()
by Alessandro Zaccagnini 16 Sep '02

16 Sep '02

Dear all, we just tried to use the functions gcd() and lcm() and we found something strange. >gcd(2*x+1, x+1/2); 1 >gcd(2*x+1, 4*x+2); 1+2*x The documentation (section 5.5.5 of GiNaC 1.0.10) says that gcd() accepts two expressions, without specifying their type. In the last sentence, it talks about polynomials, again, without specifying whether they are integer polynomials or they are allowed to have rational coefficients. Since we need the functions gcd() and lcm() very often, we would like to know as precisely as possible what is the intended behaviour. Thank you very much Alessandro Zaccagnini and Tatiana Zolo

2 1

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