- GiNaC-devel - ginac.de

[SCM] GiNaC -- a C++ library for symbolic computations branch, master, updated. release_1-4-0-421-gc42b47b
by git＠ginac.de 02 Feb '14

02 Feb '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 c42b47b4e23aea926597a9b4bee686d66d066470 (commit) from 1172e1bef381de7fc303997c7790785132e2de88 (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 c42b47b4e23aea926597a9b4bee686d66d066470 Author: Alexei Sheplyakov <Alexei.Sheplyakov(a)gmail.com> Date: Sun Feb 2 19:55:22 2014 +0200 Binary compatibilty has been broken, update the library version. commit 798d53ebb4da4e8e3865ed7bd7f31412fe2be3a7 (`Make it possible to override info() for functions.') overrides the function::info() virtual method. This breaks binary compatibility (adds a new entry in the middle of the vtable of the `function' class). The experimental proof of the above statement: ginsh linked with the previous release of libginac segfaults if libginac.so is upgraded to the current version. Thereore bump the library version. ----------------------------------------------------------------------- Summary of changes: ginac/version.h | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) hooks/post-receive -- GiNaC -- a C++ library for symbolic computations

1 0

[SCM] GiNaC -- a C++ library for symbolic computations branch, master, updated. release_1-4-0-420-g1172e1b
by git＠ginac.de 02 Feb '14

02 Feb '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 1172e1bef381de7fc303997c7790785132e2de88 (commit) via f2efaa250656be56ffc66d6c98b3384fd8d9a60d (commit) via 741cfbcecd0d64faeb843823ece888758f2a9d84 (commit) via 244c5cb90b4650deebb237eaaadc02fb90ad7682 (commit) via bed06c78cdca3df4edccd26ef3cf913b1c82be76 (commit) via a2c08961530e08935a372913c9bc9bb5c3d89d27 (commit) via a81a2c92a099f07d9451f4d182484af40aa1fe4e (commit) via bee5f67dae5b409bc53ff71cb98f6630832540e7 (commit) from 5acfced77964d811d66f83e83b8fa06d77f3edd0 (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 1172e1bef381de7fc303997c7790785132e2de88 Author: Alexei Sheplyakov <Alexei.Sheplyakov(a)gmail.com> Date: Sun Feb 2 12:56:46 2014 +0200 [build] Document that Python is required for building GiNaC. commit f2efaa250656be56ffc66d6c98b3384fd8d9a60d Author: Alexei Sheplyakov <Alexei.Sheplyakov(a)gmail.com> Date: Sun Feb 2 17:49:18 2014 +0200 [build] Fix `make pdf' for out of the source (auto* tools) build. commit 741cfbcecd0d64faeb843823ece888758f2a9d84 Author: Alexei Sheplyakov <Alexei.Sheplyakov(a)gmail.com> Date: Sun Feb 2 17:47:38 2014 +0200 [build] Include the generated sources (function.{h,cpp}) into the tarball. commit 244c5cb90b4650deebb237eaaadc02fb90ad7682 Author: Alexei Sheplyakov <Alexei.Sheplyakov(a)gmail.com> Date: Sat Feb 1 18:56:29 2014 +0200 [build] Include CMake related files into the tarball. commit bed06c78cdca3df4edccd26ef3cf913b1c82be76 Author: Alexei Sheplyakov <Alexei.Sheplyakov(a)gmail.com> Date: Sat Feb 1 18:50:37 2014 +0200 [build] Include the helper scripts into the tarball. commit a2c08961530e08935a372913c9bc9bb5c3d89d27 Author: Alexei Sheplyakov <Alexei.Sheplyakov(a)gmail.com> Date: Fri Jan 31 21:46:26 2014 +0200 check: auto* tools build: compile and run check_mul_info. commit a81a2c92a099f07d9451f4d182484af40aa1fe4e Author: Alexei Sheplyakov <Alexei.Sheplyakov(a)gmail.com> Date: Tue Jan 28 08:59:48 2014 +0200 [build] ginsh: fix `make distcheck' failure. commit bee5f67dae5b409bc53ff71cb98f6630832540e7 Author: Alexei Sheplyakov <Alexei.Sheplyakov(a)gmail.com> Date: Sat Jan 18 14:13:46 2014 +0200 log_eval: don't apply the log(x^p) -> p*log(x) rule. Automatically transforming log(p^2) into 2 log(p) might be quite annoying. Perhaps this transformation should be moved to expand() and applied only if expand_options::expand_transcendental is specified. ----------------------------------------------------------------------- Summary of changes: INSTALL | 3 ++- Makefile.am | 12 +++++++++++- check/Makefile.am | 5 +++++ check/exam_inifcns.cpp | 3 --- doc/Makefile.am | 1 + doc/examples/Makefile.am | 2 +- doc/reference/Makefile.am | 3 ++- doc/tutorial/Makefile.am | 2 +- ginac/Makefile.am | 3 ++- ginac/inifcns_trans.cpp | 5 ----- ginsh/Makefile.am | 6 +++--- tools/Makefile.am | 2 +- 12 files changed, 29 insertions(+), 18 deletions(-) hooks/post-receive -- GiNaC -- a C++ library for symbolic computations

1 0

Ulrich, please add me to your LinkedIn network
by Jose Antonio Garcia Peiro via LinkedIn 29 Jan '14

29 Jan '14

LinkedIn ------------ Jose Antonio Garcia Peiro requested to add you as a connection on LinkedIn: ------------------------------------------ I'd like to add you to my professional network on LinkedIn. Accept invitation from Jose Antonio Garcia Peiro http://www.linkedin.com/e/-smpzss-hr0w89pg-4c/pQQaivesQERn6ZpSpQQtivesQEgGd… View profile of Jose Antonio Garcia Peiro http://www.linkedin.com/e/-smpzss-hr0w89pg-4c/rso/68581204/4MAI/name/172008… ------------------------------------------ You are receiving Invitation emails. This email was intended for Ulrich Loup. Learn why this is included: http://www.linkedin.com/e/-smpzss-hr0w89pg-4c/plh/http%3A%2F%2Fhelp%2Elinke… (c) 2012, LinkedIn Corporation. 2029 Stierlin Ct, Mountain View, CA 94043, USA.

1 0

[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