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@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@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