- GiNaC-devel - ginac.de

[SCM] GiNaC -- a C++ library for symbolic computations branch, master, updated. release_1-4-0-412-g5acfced
by git＠ginac.de 28 Jan '14

28 Jan '14

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "GiNaC -- a C++ library for symbolic computations". The branch, master has been updated via 5acfced77964d811d66f83e83b8fa06d77f3edd0 (commit) from ff604e21b9108236522fb59ba5f72ba1b88b374e (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- commit 5acfced77964d811d66f83e83b8fa06d77f3edd0 Author: Stefan Weinzierl <stefanw(a)thep.physik.uni-mainz.de> Date: Tue Jan 28 08:58:06 2014 +0200 Li_eval(): avoid the "numeric::operator>(): complex inequality" exception. Basically the problem is that 1 + 0.0*I is equal to 1, but checking if the former is positive results in the the "numeric::operator>(): complex inequality" exception. This behavior is definitely inconsistent and should be fixed. As a work around teach Li_eval and convert_parameter_Li_to_H to explicitly convert 1 + 0.0*I to 1 (and -1 + 0.0*I to -1, respectively). [Alexei Sheplyakov: comment the code a little bit, otherwise it looks weird] ----------------------------------------------------------------------- Summary of changes: ginac/inifcns_nstdsums.cpp | 19 +++++++++++++++++-- 1 files changed, 17 insertions(+), 2 deletions(-) hooks/post-receive -- GiNaC -- a C++ library for symbolic computations

1 0

Floating complex numbers
by Stefan Weinzierl 21 Jan '14

21 Jan '14

Hi, I'm currently fixing some bugs in inifcns_nstdsums.cpp and came across the following strange behaviour: The GiNaC manual says "Complex numbers are automatically converted to real numbers if the imaginary part becomes zero". However, this does not seem to be the case, as the following lines show: ex w1 = numeric(3)+I*numeric(2); ex w2 = numeric(2)+I*numeric(2); ex w3 = w1-w2; if ( (w3 == 1) && ex_to<numeric>(w3).is_real() ) std::cout << "o.k., equal to one and real" << std::endl; ex z1 = numeric(3)+I*numeric("2.1"); ex z2 = numeric(2)+I*numeric("2.1"); ex z3 = z1-z2; if ( (z3 == 1) && !ex_to<numeric>(z3).is_real() ) std::cout << "bug, equal to one, but not real" << std::endl; The bug seems to be in CLN, as it does not downgrade z3 to an instance of cln::cl_R_ring. Currently this leads to an error in the file inifcns_nstdsums.cpp. In this file a variable z is first checked to be equal to +1 or -1, and later on a comparison z>0 is carried out. The comparison leads to the exception numeric::operator>(): complex inequality, since for the computer z is equal to +/- 1, but not real, similar to the last line in the code fragment above. I can work around this bug in the file inifcns_nstdsums.cpp, but the clean solution would be to fix this in CLN. Any chances for that ? Best wishes, Stefan

3 12

[SCM] GiNaC -- a C++ library for symbolic computations branch, master, updated. release_1-4-0-411-gff604e2
by git＠ginac.de 12 Jan '14

12 Jan '14

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "GiNaC -- a C++ library for symbolic computations". The branch, master has been updated via ff604e21b9108236522fb59ba5f72ba1b88b374e (commit) via 22dbae3e0d20ffd06e405100c295aeabfc0dfa5a (commit) via 9a69e9de24bc228830b5cdf02648edd860e04f8e (commit) via a4ad8cb5a89db1405fbdcaae12aef3c07904efd8 (commit) from 98433210d31a34b55c8283eb7fb7767d6c830e14 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- commit ff604e21b9108236522fb59ba5f72ba1b88b374e Author: Stefan Weinzierl <stefanw(a)thep.physik.uni-mainz.de> Date: Sun Jan 12 22:31:22 2014 +0000 Fix S_num for arguments close to the sixth root of unity or its conjugate. The method S_num within the Nielsen polylogs used to map the region abs(x)<=1 && abs(x)>0.95 && abs(1-x)<=1 && abs(1-x)>0.95 infinitely many times onto itself. This infinite recursion is now avoided. This however reveals the next problem: The numerical convergence in this region is very slow. Within the Nielsen polylogs there is no transformation available to improve the convergence. However we can use the (1-x)/(1+x) transformation within the harmonic polylogs. In order to avoid another infinite recursion I have inserted a few hold()'s in the method H_evalf, otherwise we would fall back immediately again to Nielsen polylogs. The hold()s should have been there anyway. commit 22dbae3e0d20ffd06e405100c295aeabfc0dfa5a Author: Stefan Weinzierl <stefanw(a)thep.physik.uni-mainz.de> Date: Sun Jan 12 22:19:56 2014 +0000 Fix G3_evalf and G3_eval for real and negative x. The user supplied signs of the imaginary parts are only relevant for x real and positive. A negative sign in the case of x real and negative is irrelevant (there is no branch cut) and led to wrong results. This is now avoided. commit 9a69e9de24bc228830b5cdf02648edd860e04f8e Author: Stefan Weinzierl <stefanw(a)thep.physik.uni-mainz.de> Date: Sun Jan 12 22:07:28 2014 +0000 Within mLi_numeric, set signs of the imaginary parts correctly for G_numeric. commit a4ad8cb5a89db1405fbdcaae12aef3c07904efd8 Author: Stefan Weinzierl <stefanw(a)thep.physik.uni-mainz.de> Date: Sun Jan 12 21:58:12 2014 +0000 Avoid calling log(1-x) for x=1 in Li_projection. ----------------------------------------------------------------------- Summary of changes: ginac/inifcns_nstdsums.cpp | 62 ++++++++++++++++++++++++++++++++----------- 1 files changed, 46 insertions(+), 16 deletions(-) hooks/post-receive -- GiNaC -- a C++ library for symbolic computations

1 0

Symbolic integration of trigonometric functions
by Jan 12 Jan '14

12 Jan '14

Hi, the Ginac documentation says: "GiNaC is not very good (yet?) at symbolically evaluating integrals" so I though I might help it along. Code for sin() and cos() is in this branch which is based on the current master: https://github.com/jrheinlaender/ginac/tree/jrheinlaender/integral and if you like it I might add more functions. Jan Rheinländer

2 2

Fixing log evaluation for powers
by Vladimir V. Kisil 29 Dec '13

29 Dec '13

Dear All, Making check on current master, I noticed that the following test if (!ex(log(pow(p,a))).is_equal(a*log(p))) ++result; from exam_inifnc.cpp failed. I think that the evaluation rule log(p^a) -> a*log(p), if p>0 and a is real falls out of inifcns_trans.cpp. I am attaching the corresponding patch. Best wishes, Vladimir -- Vladimir V. Kisil email: kisilv(a)maths.leeds.ac.uk www: http://www.maths.leeds.ac.uk/~kisilv/ Book: Geometry of Mobius Transformations http://www.worldscientific.com/worldscibooks/10.1142/p835

2 1

[SCM] GiNaC -- a C++ library for symbolic computations branch, master, updated. release_1-4-0-407-g9843321
by git＠ginac.de 29 Dec '13

29 Dec '13

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "GiNaC -- a C++ library for symbolic computations". The branch, master has been updated via 98433210d31a34b55c8283eb7fb7767d6c830e14 (commit) from 9ada7a7f5c47e512b7bf6057d4c013612be9a33b (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- commit 98433210d31a34b55c8283eb7fb7767d6c830e14 Author: Vladimir V. Kisil <kisilv(a)maths.leeds.ac.uk> Date: Sat Dec 28 23:58:40 2013 +0000 Fix evaluation of log(p^a) -> a*log(p), if p>0 and a is real. This evaluation was broken with commit e5c76f659e2e882d. ----------------------------------------------------------------------- Summary of changes: ginac/inifcns_trans.cpp | 7 ++++++- 1 files changed, 6 insertions(+), 1 deletions(-) hooks/post-receive -- GiNaC -- a C++ library for symbolic computations

1 0

Fix for pattern matching
by Matthias Dellweg 20 Dec '13

20 Dec '13

Dear all, while using GiNaC, I came across a strange behaviour with pattern matching in products having more than one wildcard. The match succeeded in a probablistic fashion. My conclusion is, that expairseq::match dishonors the rule, that repl_lst will remain unchanged whenever false is returned. See the attached patch, which solves the problem for me. Anyway, I started to think about the whole matching mechanism. Wouldn't it be much easier, if the matching was done from the patterns perspective? A wildcard would know itself to match to anything. And it might be possible to match a single object to a product of this object and a global wildcard, since expairseq would know how to handle that. See for example 'sin(phi).match(sin(wild(0))*wild(1))'. There could be wildcards matching to everything not containing a specified Symbol. And in every case basic would only need to check for type equality and matchable operands. I think one can even implement that preserving the current interface by calling an internal virtual match with interchanged operands. Any thoughts on that? Best wishes, Matthias Dellweg

2 5

[SCM] GiNaC -- a C++ library for symbolic computations branch, master, updated. release_1-4-0-406-g9ada7a7
by git＠ginac.de 15 Dec '13

15 Dec '13

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "GiNaC -- a C++ library for symbolic computations". The branch, master has been updated via 9ada7a7f5c47e512b7bf6057d4c013612be9a33b (commit) from e5c76f659e2e882da3d5dba60502d6851f782bf3 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- commit 9ada7a7f5c47e512b7bf6057d4c013612be9a33b Author: Matthias Dellweg <dellweg(a)tp1.uni-duesseldorf.de> Date: Tue Dec 10 10:55:28 2013 +0200 expairseq::match(): no side effects if match failed. Fixes spurious match failures. > match(sin(y)*exp(b)+sin(x)*exp(a), sin($0)*exp(a)+exp(b)*sin($1)) FAIL The reason is that expairseq::match() might assign a wildcard even if the match fails. The first attempted submatch is sin(y)*exp(b) with sin($0)*exp(a). It fails (as it should) but $0 == y gets assigned as a side effect (which is wrong). Next submatch is sin(x)*exp(a) with sin($0)*exp(a) (the same pattern as in the first submatch). This one fails because of spurious $0 == y assignment. Due to the unpredicatable term ordering the sequence of submatches might be different and the match might succeed (as it should). This makes debugging a bit more funny. Signed-off-by: Matthias Dellweg <dellweg(a)tp1.uni-duesseldorf.de> [Alexei Sheplyakov: figure out the cause of the problem, make a test case] ----------------------------------------------------------------------- Summary of changes: check/match_bug.cpp | 44 ++++++++++++++++++++++++++++++++++++++++++++ ginac/expairseq.cpp | 26 +++++++++++++++++++++----- 2 files changed, 65 insertions(+), 5 deletions(-) hooks/post-receive -- GiNaC -- a C++ library for symbolic computations

1 0

Derivative of conjugated is conjugated of derivative.
by Vladimir V. Kisil 09 Nov '13

09 Nov '13

Dear All, Further to my previous patch on functions derivatives, this small patch adds the rule conjugate(f)'=conjugate(f') to the GiNaC. The change can be seen here: cout << conjugate(log(z)).diff(z) << endl; // (before) -> z^(-1)*D[0](conjugate)(log(z)) // (now) -> conjugate(z)^(-1) Best wishes, Vladimir -- Vladimir V. Kisil email: kisilv(a)maths.leeds.ac.uk www: http://www.maths.leeds.ac.uk/~kisilv/ Book: Geometry of Mobius Transformations http://www.worldscientific.com/worldscibooks/10.1142/p835

3 8

Roots of polynomial
by Rekha Penmetsa 08 Nov '13

08 Nov '13

Hi, I am using GiNaC in my project. I want to find roots of a univariate polynomial. I am deriving a polynomial from a matrix determinant, which is coming to, 6-1/15*r-19/3138418483200*r^4-23/20713561989120000*r^5+1/18900*r^2-71/7264857600*r^3 I am using RealAlgebraicNumberFactory::realRoots() method as in the below code to find roots. I have installed GiNaCRA as well and example programs are compiling and running fine. RationalUnivariatePolynomial p(det,r); list<RealAlgebraicNumberPtr> roots = RealAlgebraicNumberFactory::realRoots( p ); This call is returning a list of zero size. Am I missing anything ? how to solve for roots for polynomials of this type? Thanks Rekha

1 0