- GiNaC-devel - ginac.de

Release 1.6.3
by Richard B. Kreckel 28 Nov '14

28 Nov '14

Hi everybody, Alexei and I have prepared a new release and are happy to announce that GiNaC 1.6.3 is out and available. These are the changes: * New expand_options::expand_transcendental. GiNaC will apply additional rules when expanding expressions if this option is specified, i.e. log(a*b) -> log(a) + log(b) exp(a + b) -> exp(a)*exp(b) * Functions can define a custom expand() and info() now. * Automatically rewrite (x^{-1})^c -> x^{-c} for positive c. * Transform abs(x)^n -> x^n if x is real and n is even. * Improved power::info(): power with a real base and even exponent reports that it's non-negative. * Fixed spurious match failure due to expairseq::match() bug: > match(sin(y)*exp(b)+sin(x)*exp(a), sin($0)*exp(a)+exp(b)*sin($1)) FAIL * Fixed power::is_polynomial() and mul::is_polynomial() computation. * factor_univariate correctly handles polynomials over rationals (no segfaults any more). * Fixed an infinite loop in factor_multivariate due to incorrect handling of polynomials having a leading coefficient being a sum with a non-trivial integer content. * Fixed numeric evaluation of generalized multiple polylogarithms for real and negative argument. * Avoid calling log(1-x) in numeric evaluation of classical polylogarithm. * Fixed numeric evaluation of multiple polylogarithms (correctly set the signs of the imaginary parts in the intermediate expression). * Fixed numeric evaluation of Nielsen polylogs for arguments close to the 6th root of unity or its conjugate. * Avoid infinite recursion in series expansion of logarithm. * numeric::info(info_flags::nonnegative) correctly handles complex numbers with non-zero imaginary part. * Fixed several build issues: - libreadline and dlopen() misdetection. - multiple definition of symbol on MinGW. - auto* tools and texinfo being unhappy in various ways. * GiNaC can be built with CMake now. Regards, -richy. -- Richard B. Kreckel <http://in.terlu.de/~kreckel/>

1 0

[SCM] GiNaC -- a C++ library for symbolic computations tag, ginac_1-6-3, created. release_1-4-0-437-gcfdc2c3
by git＠ginac.de 27 Nov '14

27 Nov '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 tag, ginac_1-6-3 has been created at cfdc2c31088bb196426dd071de5181248df2e160 (commit) - Log ----------------------------------------------------------------- commit cfdc2c31088bb196426dd071de5181248df2e160 Author: Richard Kreckel <kreckel(a)ginac.de> Date: Thu Nov 27 21:29:39 2014 +0000 Finalized 1.6.3 release. Updated NEWS file, moved some comments so Doxygen won't be confused. ----------------------------------------------------------------------- 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-437-gcfdc2c3
by git＠ginac.de 27 Nov '14

27 Nov '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 cfdc2c31088bb196426dd071de5181248df2e160 (commit) from 55a08d9cb9005bb10def92d5e8f5a816003da16b (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 cfdc2c31088bb196426dd071de5181248df2e160 Author: Richard Kreckel <kreckel(a)ginac.de> Date: Thu Nov 27 21:29:39 2014 +0000 Finalized 1.6.3 release. Updated NEWS file, moved some comments so Doxygen won't be confused. ----------------------------------------------------------------------- Summary of changes: NEWS | 11 ++++------- ginac/crc32.h | 8 +++++--- ginac/hash_seed.h | 27 ++++++++++++++++----------- 3 files changed, 25 insertions(+), 21 deletions(-) hooks/post-receive -- GiNaC -- a C++ library for symbolic computations

1 0

[SCM] GiNaC -- a C++ library for symbolic computations tag, release_1-6-3, created. release_1-4-0-437-g2c7d26f
by git＠ginac.de 27 Nov '14

27 Nov '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 tag, release_1-6-3 has been created at 2c7d26f82ab2938ccc42372459a6640137a910a1 (commit) - Log ----------------------------------------------------------------- commit 2c7d26f82ab2938ccc42372459a6640137a910a1 Author: Richard Kreckel <kreckel(a)ginac.de> Date: Thu Nov 27 21:29:39 2014 +0000 Finilized 1.6.3 release. Updated NEWS file, moved some comments so Doxygen won't be confused. ----------------------------------------------------------------------- hooks/post-receive -- GiNaC -- a C++ library for symbolic computations

1 0

Derivative of conjugated and even power of modulus (resubmission)
by Vladimir V. Kisil 29 Oct '14

29 Oct '14

Dear All, I am attaching two simple 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://maths.leeds.ac.uk/~kisilv/

1 0

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

27 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 55a08d9cb9005bb10def92d5e8f5a816003da16b (commit) from cca88b51436e4b654d16a4d60cd0d1c66fcf5dd6 (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 55a08d9cb9005bb10def92d5e8f5a816003da16b Author: Alexei Sheplyakov <Alexei.Sheplyakov(a)gmail.com> Date: Sun Jan 19 19:50:23 2014 +0200 Prepare for 1.6.3 release. ----------------------------------------------------------------------- Summary of changes: NEWS | 38 ++++++++++++++++++++++++++++++++++++++ ginac/version.h | 2 +- 2 files changed, 39 insertions(+), 1 deletion(-) hooks/post-receive -- GiNaC -- a C++ library for symbolic computations

2 1

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

14 Oct '14

1 0

[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