October 2014 - GiNaC-devel

04 Jun '15

Hi, is there any reason not to define the derivative of the built-in abs() function as either abs(x)/x or csgn(x) ? Currently it has not derivative defined at all. Regards, Jan

5 8

Implicit derivation of functions (re-submission)
by Vladimir V. Kisil 02 Feb '15

02 Feb '15

Dear All, I am resending the patch for implicit derivation of functions. Quote from the previous submission: http://www.ginac.de/pipermail/ginac-devel/2013-November/002053.html " I wish to propose another GiNaC extension. Consider function abs(). Since it can be presented as abs(z)=sqrt(z*z.conjugate()), the derivative of abs(f) may be calculated as (abs(f))'=(f'*f.conjugate()+f*f'.conjugate())/2/abs(f) However, this formula cannot be packed into the present GiNaC code, since it only knows about the chain rule. Thus, the patch adds a possibility to define derivatives of functions in some general expression. In particular, the above derivative of abs() is defined. Example: cout << abs(log(z)).diff(z) << endl; // (before) -> D[0](abs)(log(z))*z^(-1) // (now) -> 1/2*(z^(-1)*conjugate(log(z))+log(z)*conjugate(z)^(-1))*abs(log(z))^(-1) " This issue independently appeared in this discussion: http://www.ginac.de/pipermail/ginac-devel/2014-April/002106.html If it is not included in the core code, then a user need to redefine the entire GiNaC function class to have this feature. Best wishes, Vladimir -- Vladimir V. Kisil email: kisilv(a)maths.leeds.ac.uk -- www: http://maths.leeds.ac.uk/~kisilv/

2 6

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