- GiNaC-devel - ginac.de

[SCM] GiNaC -- a C++ library for symbolic computations branch, master, updated. release_1-4-0-646-g9985e288
by Richard B. Kreckel 01 Jan '20

01 Jan '20

1 0

MinGW64 compilation fix
by Alexey Sheplyakov 12 Dec '19

12 Dec '19

Hi! The attached patch makes GiNaC compile for 64-bit Windows (with GCC compiler). The problem was constructing expressions from std::size_t. On 64-bit Windows std::size_t is unsigned long long (same as uint64_t) and there were no constructors taking long long. Best regards, Alexey

2 1

[SCM] GiNaC -- a C++ library for symbolic computations branch, master, updated. release_1-4-0-645-gbb2866ed
by Richard B. Kreckel 12 Dec '19

12 Dec '19

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 bb2866ed001b2dd297fa83573ffc10dd95a12c97 (commit) from f2051c351d8f9791a4afcc8d03465bf100a8088d (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 bb2866ed001b2dd297fa83573ffc10dd95a12c97 Author: Alexey Sheplyakov <asheplyakov(a)altlinux.org> Date: Thu Dec 12 08:38:18 2019 +0100 [PATCH] numeric, ex: added constructors taking `long long`. Fixes MinGW64 build. On 64-bit windows std::size_t is `unsigned long long` (64 bit). However there is no ex constructor taking (unsigned) long long. This patch adds ex and numeric constructors taking `long long` and `unsigned long long`. ----------------------------------------------------------------------- Summary of changes: ginac/ex.cpp | 20 +++++++++++++++++++- ginac/ex.h | 16 ++++++++++++++++ ginac/numeric.cpp | 11 +++++++++++ ginac/numeric.h | 2 ++ 4 files changed, 48 insertions(+), 1 deletion(-) hooks/post-receive -- GiNaC -- a C++ library for symbolic computations

1 0

Domain of symbol
by Vladimir V. Kisil 09 Nov '19

09 Nov '19

Dear All, Consider the code: #include <iostream> #include <ginac/ginac.h> using namespace std; using namespace GiNaC; int main() { for (int i=0; i < 2; ++i) (i==0? realsymbol("r") : symbol("s")).dbgprinttree(); return 0; } My expectation would be that it first creates a realsymbol r and then a symbol s. However, the actual output of the programme is: r (symbol) @0x7fff6e472700, serial=1, hash=0x1689b718, flags=0x6, domain=0 s (symbol) @0x7fff6e472700, serial=2, hash=0x1689b718, flags=0x6, domain=0 That is, in both cases the domain is 0 (complex) and r is not recognised as a real symbol. Shall this be corrected or did I misunderstand the concept of (A? B : C) construct? Best wishes, Vladimir PS Another (less important and more disputable) question: do we want the debug output for realsymbol/possymbol look like r (realsymbol) @0x7fff6e472700, serial=1, hash=0x1689b718, flags=0x6, domain=1 p (possymbol) @0x7fff6e472700, serial=1, hash=0x1689b718, flags=0x6, domain=2 to make the class more visible? -- Vladimir V. Kisil http://www.maths.leeds.ac.uk/~kisilv/ Book: Geometry of Mobius Transformations http://goo.gl/EaG2Vu Software: Geometry of cycles http://moebinv.sourceforge.net/ Jupyter (Colab): https://github.com/vvkisil/MoebInv-notebooks Jupyter (CodeOcean): https://codeocean.com/capsule/7952650/tree

2 2

Windows 64 Bit Build
by Richard Crozier 23 Oct '19

23 Oct '19

Dear list, I am trying to cross-compile ginac for windows. To do this I am using M Cross Environment (see www.mxe.cc for more info) to cross-compile ginac from windows. MXE automatically creates a cross-compilation environment for you that integrates with autotools, cmak or normal makefiles. Using MXE I successfully built the CLN library from the w64 branch of this git repository: https://github.com/jrheinlaender/cln/tree/w64 Now I am trying to build ginac itself, but am getting the following error: /bin/bash ../libtool --tag=CXX --mode=compile x86_64-w64-mingw32.static-g++ -std=gnu++11 -DHAVE_CONFIG_H -I. -I../config -DLIBEXECDIR='"/opt/mxe/usr/x86_64-w64-mingw32.static/libexec/"' -std=c++11 -MT libginac_la-fderivative.lo -MD -MP -MF .deps/libginac_la-fderivative.Tpo -c -o libginac_la-fderivative.lo `test -f 'fderivative.cpp' || echo './'`fderivative.cpp libtool: compile: x86_64-w64-mingw32.static-g++ -std=gnu++11 -DHAVE_CONFIG_H -I. -I../config -DLIBEXECDIR=\"/opt/mxe/usr/x86_64-w64-mingw32.static/libexec/\" -std=c++11 -MT libginac_la-fderivative.lo -MD -MP -MF .deps/libginac_la-fderivative.Tpo -c fderivative.cpp -DDLL_EXPORT -DPIC -o .libs/libginac_la-fderivative.o factor.cpp: In function 'GiNaC::ex GiNaC::{anonymous}::factor_multivariate(const GiNaC::ex&, const exset&)': factor.cpp:2254:56: error: conversion from 'long long unsigned int' to 'GiNaC::numeric' is ambiguous numeric modulus = (vnlst.nops() > 3) ? vnlst.nops() : 3; ^ In file included from factor.cpp:58:0: numeric.h:94:2: note: candidate: GiNaC::numeric::numeric(double) numeric(double d); ^ numeric.h:92:2: note: candidate: GiNaC::numeric::numeric(long unsigned int) numeric(unsigned long i); ^ numeric.h:91:2: note: candidate: GiNaC::numeric::numeric(long int) numeric(long i); ^ numeric.h:90:2: note: candidate: GiNaC::numeric::numeric(unsigned int) numeric(unsigned int i); ^ numeric.h:89:2: note: candidate: GiNaC::numeric::numeric(int) numeric(int i); ^ This is from the master barnch of the git repository, but I get the same error using the latest release. Is there likely to be an easy fix, or is my quest in vain? If you are interested at all, I built CLN using MXE like this: autoreconf -iv ./configure --host=x86_64-w64-mingw32.static CXXFLAGS="$CXXFLAGS -std=c++11" --prefix=/opt/mxe/usr/x86_64-w64-mingw32.static make -j3 make install However, I should mention that I also manually removed the subdirectories tests, examples, doc and benchmarks from the Makefile.am and configure.ac before building. I then tried to build ginac the exact same way: autoreconf -i ./configure --host=x86_64-w64-mingw32.static CXXFLAGS="$CXXFLAGS -std=c++11" --prefix=/opt/mxe/usr/x86_64-w64-mingw32.static make -j3 make install Regards, Richard

2 2

Release 1.7.8
by Richard B. Kreckel 07 Oct '19

07 Oct '19

Hi, GiNaC 1.7.8 has just been released. The changes are: * Fix pseries::evalf(), broken since 1.7.0. * Fix a corner-case bug in H_evalf(). Happy hacking! -richy. -- Richard B. Kreckel <https://in.terlu.de/~kreckel/>

1 0

[SCM] GiNaC -- a C++ library for symbolic computations tag, release_1-7-8, created. release_1-4-0-644-gf2051c35
by Richard B. Kreckel 07 Oct '19

07 Oct '19

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-7-8 has been created at f2051c351d8f9791a4afcc8d03465bf100a8088d (commit) - Log ----------------------------------------------------------------- commit f2051c351d8f9791a4afcc8d03465bf100a8088d Author: Richard Kreckel <kreckel(a)ginac.de> Date: Mon Oct 7 22:23:54 2019 +0200 Finalize 1.7.8 release. ----------------------------------------------------------------------- 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-644-gf2051c35
by Richard B. Kreckel 07 Oct '19

07 Oct '19

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 f2051c351d8f9791a4afcc8d03465bf100a8088d (commit) from 0eaae44cd9eb9fa987bb9cbd4341b0f4c8d2f495 (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 f2051c351d8f9791a4afcc8d03465bf100a8088d Author: Richard Kreckel <kreckel(a)ginac.de> Date: Mon Oct 7 22:23:54 2019 +0200 Finalize 1.7.8 release. ----------------------------------------------------------------------- Summary of changes: NEWS | 4 ++++ ginac/version.h | 4 ++-- 2 files changed, 6 insertions(+), 2 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-643-g0eaae44c
by Richard B. Kreckel 07 Oct '19

07 Oct '19

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 0eaae44cd9eb9fa987bb9cbd4341b0f4c8d2f495 (commit) from 84ebcf26ac5ac91fcfceb67c226167cbc08a4929 (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 0eaae44cd9eb9fa987bb9cbd4341b0f4c8d2f495 Author: Stefan Weinzierl <weinzierl(a)uni-mainz.de> Date: Mon Oct 7 20:32:01 2019 +0200 Fix bug in H_evalf: Flag has_minus_one is now computed where it is needed. This bug has been reported and fixed by Yannick Ulrich <yannick.ulrich(a)psi.ch>. ----------------------------------------------------------------------- Summary of changes: ginac/inifcns_nstdsums.cpp | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-) hooks/post-receive -- GiNaC -- a C++ library for symbolic computations

1 0

Evaluation of generalised and harmonic polylogarithms
by Yannick Ulrich 07 Oct '19

07 Oct '19

Dear all, while working on our program handyG [1909.01656] for the numerical evaluation of GPLs, I've noticed that my installation of GiNaC (1.7.7) throws an error for a certain class of GPLs. An example of such a GPL is G(x,y,x; 1.) with x=1/100 + I/8 and y =-1/8 G({x,y,x},1.); map_trafo_H_1mx: cannot handle weights equal -1! I tried to analyse the problem and (probably) traced it back to the evaluation of Li({1,2}, {x/y, 1}) == Li({1,2}, {z, 1}) = H({1,0,1},z) with z = x/y = -2/25 - I which throws the same error. As far as I understand, the HPLs are evaluated as follows (all line numbers refer to inifcns_nstdsums.cpp) * To speed up convergence for some range of values, a transformation x -> 1-x is performed, assuming all weights are positive (otherwise the transformation is not well-defined). This happens in line 3314. * The error is thrown if there are negative weights being transformed (line 2845). * In line 3227-3244, the parameter list m is populated using integers. A bool variable has_minus_one is set to true (3239) should one of weights be negative in order to not attempt the transformation to 1-x * I understand lines 3279-3287 to check whether Re[x] > 0 and to transform to guarantee this if need be. Part of the transformation (line 3283) requires m[i] -> -m[i]. If m[i] used to be positive, this means that m[i] is now negative. * Because has_minus_one does not seem to be re-computed after this re-mapping, it is possible to trip up GiNaC with HPLs. * We need to require the transformation x -> 1-x, i.e. - |x| > 0.95 to avoid direct summation (line 3246), - |x| < 2 to avoid the transformation x->1/x (line 3290), and - |(1-z)/(1+z)| > 0.9 with z = -x. * We need to guarantee that the problematic mapping x->-x occurs, i.e. Re[x] < 0. This results in two rather small regions (measure is just 0.36) just left of the imaginary axis with 1 < |Im[x]|| < 2. * m needs to contain +1 and not have no trailing zeros. A rather trivial fix for this would be just to re-check has_minus_one like so --------------------------------------------------------------------- diff --git a/ginac/inifcns_nstdsums.cpp b/ginac/inifcns_nstdsums.cpp index f040e8ad..c08cd32b 100644 --- a/ginac/inifcns_nstdsums.cpp +++ b/ginac/inifcns_nstdsums.cpp @@ -3300,6 +3300,9 @@ static ex H_evalf(const ex& x1, const ex& x2) // check transformations for 0.95 <= |x| < 2.0 + for (auto const& i : m) { + if (i == -1) has_minus_one = true; + } // |(1-x)/(1+x)| < 0.9 -> circular area with center=9.53+0i and radius=9.47 if (cln::abs(x-9.53) <= 9.47) { // x -> (1-x)/(1+x) --------------------------------------------------------------------- Having applied this patch, the offending HPL discussed above comes out with its correct value of H({1,0,1},z) = -0.25454297772039644317+0.27861285229476603358 I have compared this to Daniel Maitre's HPL [hep-ph/0703052] and find it match. I'm looking forward to your feedback. Cheers, Yannick

3 3