- GiNaC-devel - ginac.de

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

12 Oct '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 cda7fd319d75f95fbdac21213a10a04de724d228 (commit) via 40b0071bbe4055bbae533634f008af38503ab696 (commit) from 9e80b0d339d1ce83f51e0eb5fb101c41f23f6a71 (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 cda7fd319d75f95fbdac21213a10a04de724d228 Author: Stefan Weinzierl <stefanw(a)thep.physik.uni-mainz.de> Date: Sun Oct 12 18:30:41 2014 +0000 Fix log() error in multiple polylog G. Tobias Huber reported the following bug: > G({-0.18784426860496276*I,-0.1579006477353911*I,+0.18784426860496276*I,-0.18784426860496276*I},1); log_eval(): log(0) The problem is the sorting operation in G_do_trafo. This operation should 1) put the elements in increasing order of |x| 2) put equal elements next to each other (which then will avoid the log(0) problem). The current code fails for goal 2) if we have complex numbers of equal absolute value, one number occuring more than once, in an initial order like in the example above: Entries 1,3,4 of the list all have the same absolute value, entries 1 and 4 are equal. In the sorting operation 1 and 4 should be put next to each other. Previously, the sorting operation would give 2,1,3,4. What we would like to have is either 2,1,4,3 or 2,3,1,4. It is clear that the key for the sorting operation cannot be |x| alone. If |x1|=|x2| we have to use the phase as well. This patch takes the phase into account in the sorting. commit 40b0071bbe4055bbae533634f008af38503ab696 Author: Stefan Weinzierl <stefanw(a)thep.physik.uni-mainz.de> Date: Sun Oct 12 18:24:07 2014 +0000 Fix evaluation of some G-polylogs. This patch corrects and supersedes the patches 97ef604e "G_numeric: fix numeric evaluation with trailing zeros and y != 1." and 9e80b0d3 "G_numeric: fix evaluation with y == 1". The original motivation for 97ef604e was to make sure that Hoelder convolution is only used if there no trailing zeros. Patch 97ef604e delegated the case of trailing zeros to G_do_trafo, which correctly removes the trailing zeros, but in addition also performed the transformation described in sect. 5.3 of hep-ph/0410259 ("convergence transformation"). The inappropriate call of the convergence transformation is the cause of the new bug reported at http://www.cebix.net/pipermail/ginac-list/2014-September/002011.html The patch 9e80b0d3 cures the symptons mentioned in the above bug report, but fails for other cases, like evalf( G({-2,2,-2,0},2) ). What should be done is the following: If trailing zeros are detected in G_numeric, these should be removed and the result should be returned to G_numeric. The routine G_numeric decides then what to do next: either calling the convergence transformation, or Hoelder convolution or direct summation. What is needed is a subroutine, which just removes trailing zeros, but does not perform the convergence transformation. With the present code the minimal modification to achieve this goal is to add an additional boolean parameter flag_trailing_zeros_only to G_do_trafo (and its dependent sub-routines), so G_do_trafo can be called for the removal of trailing zeros only. This patch implements this and uses G_do_trafo to remove trailing zeros only for the case at hand. ----------------------------------------------------------------------- Summary of changes: ginac/inifcns_nstdsums.cpp | 86 +++++++++++++++++++++++++++------------------- 1 file changed, 51 insertions(+), 35 deletions(-) hooks/post-receive -- GiNaC -- a C++ library for symbolic computations

1 0

G_do_trafo: bug fix for sort operation
by Stefan Weinzierl 10 Oct '14

10 Oct '14

Hello, Tobias Huber reported the following bug: > G({-0.18784426860496276*I,-0.1579006477353911*I,+0.18784426860496276*I,-0.18784426860496276*I},1); log_eval(): log(0) The problem is the sorting operation in G_do_trafo. This operation should 1) put the elements in increasing order of |x| 2) put equal elements next to each other (which then will avoid the log(0) problem). The current code fails for goal 2) if we have complex numbers of equal absolute value, one number occuring more than once, in an initial order like in the example above: Entries 1,3,4 of the list all have the same absolute value, entries 1 and 4 are equal. In the sorting operation 1 and 4 should be put next to each other. Previously, the sorting operation would give 2,1,3,4. What we would like to have is either 2,1,4,3 or 2,3,1,4. It is clear, that the key for the sorting operation cannot be |x| alone. In the case of |x1|=|x2| we have to use the phase information as well. The patch implements this. Best wishes, Stefan

1 0

Bugfix "commit 97ef604e breaks evaluation of some G-polylogs"
by Stefan Weinzierl 22 Sep '14

22 Sep '14

Hello, the attached patch corrects and supersedes the patches 97ef604e "G_numeric: fix numeric evaluation with trailing zeros and y != 1." and 9e80b0d3 "G_numeric: fix evaluation with y == 1". The original motivation for patch 97ef604e was to make sure that Hoelder convolution is only used if there no trailing zeros. Patch 97ef604e delegated the case of trailing zeros to G_do_trafo, which correctly removes the trailing zeros, but in addition also performed the transformation described in sect. 5.3 of hep-ph/0410259 ("convergence transformation"). The inappropriate call of the convergence transformation is the cause of the new bug reported at http://www.cebix.net/pipermail/ginac-list/2014-September/002011.html The patch 9e80b0d3 cures the symptons mentioned in the above bug report, but fails for other cases, like evalf( G({-2,2,-2,0},2) ). What should be done is the following: If trailing zeros are detected in G_numeric, these should be removed and the result should be returned to G_numeric. The routine G_numeric decides then what to do next: either calling the convergence transformation, or Hoelder convolution or direct summation. What is needed is a subroutine, which just removes trailing zeros, but does not perform the convergence transformation. With the present code the minimal modification to achieve this goal is to add an additional boolean parameter flag_trailing_zeros_only to G_do_trafo (and its dependent sub-routines), so G_do_trafo can be called for the removal of trailing zeros only. The proposed patch implements this and uses G_do_trafo to remove trailing zeros only for the case at hand. Best wishes, Stefan

1 0

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

12 Sep '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 9e80b0d339d1ce83f51e0eb5fb101c41f23f6a71 (commit) from 708491c9e2df3690d58f1d93e4bd0506baeac103 (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 9e80b0d339d1ce83f51e0eb5fb101c41f23f6a71 Author: Alexei Sheplyakov <Alexei.Sheplyakov(a)gmail.com> Date: Fri Sep 12 17:50:51 2014 +0400 G_numeric: fix evaluation with y == 1 Do apply Hoelder convolution if y == 1 even if there are trailing zeros. Fixes the regression introduced by commit 97ef604e ("G_numeric: fix numeric evaluation with trailing zeros and y != 1.") ----------------------------------------------------------------------- Summary of changes: check/exam_inifcns_nstdsums.cpp | 28 ++++++++++++++++++++++++++++ ginac/inifcns_nstdsums.cpp | 9 ++++++--- 2 files changed, 34 insertions(+), 3 deletions(-) hooks/post-receive -- GiNaC -- a C++ library for symbolic computations

1 0

Two previous patches
by Vladimir V. Kisil 10 Sep '14

10 Sep '14

Dear All, I am attaching two patches which were submitted in Nov 2013, and discussed at http://www.ginac.de/pipermail/ginac-devel/2013-November/ The first patch was modified after this discussion and no further objection were raised to either of them. 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

1 0

[SCM] GiNaC -- a C++ library for symbolic computations branch, master, updated. release_1-4-0-430-g708491c
by git＠ginac.de 08 Sep '14

08 Sep '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 708491c9e2df3690d58f1d93e4bd0506baeac103 (commit) from d55314ec284f24063e949c5c3f3ee57011ddb283 (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 708491c9e2df3690d58f1d93e4bd0506baeac103 Author: Alexei Sheplyakov <Alexei.Sheplyakov(a)gmail.com> Date: Sun Sep 7 22:56:02 2014 +0400 Add more ex::is_polynomial() tests Improves commit 92da4c16 ('[bugfix] ex::is_polynomial(x): fix miscomputations') a little bit. ----------------------------------------------------------------------- Summary of changes: check/exam_paranoia.cpp | 23 +++++++++++++++++++++++ 1 files changed, 23 insertions(+), 0 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-429-gd55314e
by git＠ginac.de 07 Sep '14

07 Sep '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 d55314ec284f24063e949c5c3f3ee57011ddb283 (commit) from 92da4c16f5d6edf276be011a08ce04b352945a83 (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 d55314ec284f24063e949c5c3f3ee57011ddb283 Author: Vladimir V. Kisil <kisilv(a)maths.leeds.ac.uk> Date: Mon Aug 18 21:29:01 2014 +0100 Providing default (un)archiving for cliffordunit class. Signed-off-by: Vladimir V. Kisil <kisilv(a)maths.leeds.ac.uk> ----------------------------------------------------------------------- Summary of changes: ginac/clifford.cpp | 1 + ginac/clifford.h | 1 + 2 files changed, 2 insertions(+), 0 deletions(-) hooks/post-receive -- GiNaC -- a C++ library for symbolic computations

1 0

Archiving symbols with empty names
by Vladimir V. Kisil 22 Aug '14

22 Aug '14

Dear All, Developing an archiving routine for a GiNaC derived class I met the following problem. Some code (e.g. clifford.cpp) creates indexed objects with several dynamically created indexes labelled by new symbols with empty names. If such indexed objects are archived, then empty-named symbols are treated as identical and the restored object has a wrong number of indexes (only one). There is a line in void symbol::archive(archive_node &n) const, telling // XXX: we should not archive anonymous symbols. Shall this be fixed somehow? 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

1 0

(un)archive cliffordunit
by Vladimir V. Kisil 18 Aug '14

18 Aug '14

Dear All, It comes to my attention that cliffordunit class was not supplied with (un)archiving methods. I am attaching a trivial patch for this. 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

1 0

why does power(add) switch the sign of the add?
by Jan 13 Aug '14

13 Aug '14

Hi, I noticed the following behaviour of power::eval(), for example in ginsh: > (x_1 - x_2 + x_3 - x_4)^2; (x_4-x_1-x_3+x_2)^2 The sign of the sum is switched. Of course, mathematically this is totally correct, but is there any good reason why GiNaC should do it? It seems to go back to the following piece of code in power.cpp, power::eval() --------- // (2*x + 6*y)^(-4) -> 1/16*(x + 3*y)^(-4) if (num_exponent->is_integer() && is_exactly_a<add>(ebasis)) { numeric icont = ebasis.integer_content(); const numeric lead_coeff = ex_to<numeric>(ex_to<add>(ebasis).seq.begin()->coeff).div(icont); const bool canonicalizable = lead_coeff.is_integer(); >>> HERE ============================ const bool unit_normal = lead_coeff.is_pos_integer(); if (canonicalizable && (! unit_normal)) icont = icont.mul(*_num_1_p); >>> HERE ============================ if (canonicalizable && (icont != *_num1_p)) { const add& addref = ex_to<add>(ebasis); add* addp = new add(addref); addp->setflag(status_flags::dynallocated); addp->clearflag(status_flags::hash_calculated); addp->overall_coeff = ex_to<numeric>(addp->overall_coeff).div_dyn(icont); for (epvector::iterator i = addp->seq.begin(); i != addp->seq.end(); ++i) i->coeff = ex_to<numeric>(i->coeff).div_dyn(icont); const numeric c = icont.power(*num_exponent); if (likely(c != *_num1_p)) return (new mul(power(*addp, *num_exponent), c))->setflag(status_flags::dynallocated); else return power(*addp, *num_exponent); } } ------------ Why not leave away this bit of code, improve performance by a tiny little bit, and get somewhat more predictable behaviour of GiNaC? Jan

2 1