From kreckel at in.terlu.de Tue Oct 1 23:55:00 2019 From: kreckel at in.terlu.de (Richard B. Kreckel) Date: Tue, 1 Oct 2019 23:55:00 +0200 Subject: [GiNaC-devel] pseries::evalf() and pseries::eval() In-Reply-To: <30554.1569789314@math-pc2069.leeds.ac.uk> References: <30554.1569789314@math-pc2069.leeds.ac.uk> Message-ID: Dear Vladimir, On 29.09.19 22:35, Vladimir V. Kisil wrote: > GiNaC tutorial in section "2.2 What it can do for you" says > that Ginsh shall produce: > > > series(tgamma(x),x==0,3); > x^(-1)-Euler+(1/12*Pi^2+1/2*Euler^2)*x+ > (-1/3*zeta(3)-1/12*Pi^2*Euler-1/6*Euler^3)*x^2+Order(x^3) > > evalf(%); > x^(-1)-0.5772156649015328606+(0.9890559953279725555)*x > -(0.90747907608088628905)*x^2+Order(x^3) > > However, with the current GiNaC versions the second output will be > identical to the first. I am attaching a small patch which shall > restore the expected output. Thanks for reporting this! It is a regression introduced in f8c2455fbb. I assume you just added the eval() method to it.rest in pseries::eval() because of symmetry? There shouldn't be any need to do so since 1.7.0. All my best, -richy. -- Richard B. Kreckel From kisilv at maths.leeds.ac.uk Wed Oct 2 00:21:54 2019 From: kisilv at maths.leeds.ac.uk (Vladimir V. Kisil) Date: Tue, 01 Oct 2019 23:21:54 +0100 Subject: [GiNaC-devel] pseries::evalf() and pseries::eval() In-Reply-To: References: <30554.1569789314@math-pc2069.leeds.ac.uk> Message-ID: <18813.1569968514@math-pc2069.leeds.ac.uk> >>>>> On Tue, 1 Oct 2019 23:55:00 +0200, "Richard B. Kreckel" said: RK> I assume you just added the eval() method to it.rest in RK> pseries::eval() because of symmetry? There shouldn't be any need RK> to do so since 1.7.0. Yes, I did it formally... -- 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 From git at ginac.de Wed Oct 2 08:23:52 2019 From: git at ginac.de (Richard B. Kreckel) Date: Wed, 2 Oct 2019 08:23:52 +0200 (CEST) Subject: [GiNaC-devel] [SCM] GiNaC -- a C++ library for symbolic computations branch, master, updated. release_1-4-0-641-g05d274b8 Message-ID: <20191002062352.EA496D801DE@cebix.net> 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 05d274b894f2f84217d308bf4d4f2202b9627c63 (commit) from d3ed10100d250016e9fd0bcf24f221ea2be759fa (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 05d274b894f2f84217d308bf4d4f2202b9627c63 Author: Vladimir V. Kisil Date: Wed Oct 2 00:00:09 2019 +0200 Fix pseries::evalf() regression. Since f8c2455fbb, rest was not evalf()'ed any more. ----------------------------------------------------------------------- Summary of changes: ginac/pseries.cpp | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) hooks/post-receive -- GiNaC -- a C++ library for symbolic computations From git at ginac.de Thu Oct 3 23:09:31 2019 From: git at ginac.de (Richard B. Kreckel) Date: Thu, 3 Oct 2019 23:09:31 +0200 (CEST) Subject: [GiNaC-devel] [SCM] GiNaC -- a C++ library for symbolic computations branch, master, updated. release_1-4-0-642-g84ebcf26 Message-ID: <20191003210931.B68DAD802A5@cebix.net> 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 84ebcf26ac5ac91fcfceb67c226167cbc08a4929 (commit) from 05d274b894f2f84217d308bf4d4f2202b9627c63 (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 84ebcf26ac5ac91fcfceb67c226167cbc08a4929 Author: Richard Kreckel Date: Thu Oct 3 23:08:24 2019 +0200 Trivialize pseries::eval(). Since 1.7.0, the elements are eval()'ed, so there's nothing to do any more for pseries::eval(). ----------------------------------------------------------------------- Summary of changes: ginac/pseries.cpp | 12 +----------- 1 file changed, 1 insertion(+), 11 deletions(-) hooks/post-receive -- GiNaC -- a C++ library for symbolic computations From yannick.ulrich at psi.ch Fri Oct 4 15:01:08 2019 From: yannick.ulrich at psi.ch (Yannick Ulrich) Date: Fri, 4 Oct 2019 15:01:08 +0200 Subject: [GiNaC-devel] Evaluation of generalised and harmonic polylogarithms Message-ID: 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 From weinzierl at uni-mainz.de Sat Oct 5 11:59:45 2019 From: weinzierl at uni-mainz.de (Stefan Weinzierl) Date: Sat, 5 Oct 2019 11:59:45 +0200 Subject: [GiNaC-devel] Evaluation of generalised and harmonic polylogarithms In-Reply-To: References: Message-ID: Dear Yannick, thanks for reporting this bug and the solution to fix it. Your absolutely right, has_minus_one needs to be recomputed. Actually, it is never used before and just needs to be computed at this place. Attached is a minor modification of your patch, taking this into account. Richy: Can you apply the patch? Best wishes, Stefan -------------- next part -------------- A non-text attachment was scrubbed... Name: polylog14.patch Type: text/x-diff Size: 1056 bytes Desc: patch file URL: From kreckel at in.terlu.de Sun Oct 6 23:31:36 2019 From: kreckel at in.terlu.de (Richard B. Kreckel) Date: Sun, 6 Oct 2019 23:31:36 +0200 Subject: [GiNaC-devel] Evaluation of generalised and harmonic polylogarithms In-Reply-To: References: Message-ID: <113628ab-50f5-e969-f0d4-d2a57fb214c4@in.terlu.de> On 05.10.19 11:59, Stefan Weinzierl wrote: > Richy: Can you apply the patch? Sure. Could you, please, re-send it together with a good git comment? (While at it: Are you sure about the source code comment "check for letters"?) All my best, -richy. From weinzierl at uni-mainz.de Mon Oct 7 12:41:06 2019 From: weinzierl at uni-mainz.de (Stefan Weinzierl) Date: Mon, 7 Oct 2019 12:41:06 +0200 Subject: [GiNaC-devel] Evaluation of generalised and harmonic polylogarithms In-Reply-To: <113628ab-50f5-e969-f0d4-d2a57fb214c4@in.terlu.de> References: <113628ab-50f5-e969-f0d4-d2a57fb214c4@in.terlu.de> Message-ID: Dear Richy, no problem. Git comment: "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 ." The source code comment is fine, in particular it's helpful for the people from the polylog community. I'm not insisting on it, feel free to remove it if you don't like it. Best wishes, Stefan On Sun, 6 Oct 2019, Richard B. Kreckel wrote: > On 05.10.19 11:59, Stefan Weinzierl wrote: >> Richy: Can you apply the patch? > > Sure. Could you, please, re-send it together with a good git comment? > (While at it: Are you sure about the source code comment "check for > letters"?) > > All my best, > -richy. > _______________________________________________ > GiNaC-devel mailing list > GiNaC-devel at ginac.de > https://www.cebix.net/mailman/listinfo/ginac-devel > -------------- next part -------------- A non-text attachment was scrubbed... Name: polylog14.patch Type: text/x-diff Size: 1056 bytes Desc: patch file URL: From git at ginac.de Mon Oct 7 20:32:57 2019 From: git at ginac.de (Richard B. Kreckel) Date: Mon, 7 Oct 2019 20:32:57 +0200 (CEST) Subject: [GiNaC-devel] [SCM] GiNaC -- a C++ library for symbolic computations branch, master, updated. release_1-4-0-643-g0eaae44c Message-ID: <20191007183257.0239FD8037D@cebix.net> 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 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 . ----------------------------------------------------------------------- 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 From git at ginac.de Mon Oct 7 22:35:00 2019 From: git at ginac.de (Richard B. Kreckel) Date: Mon, 7 Oct 2019 22:35:00 +0200 (CEST) Subject: [GiNaC-devel] [SCM] GiNaC -- a C++ library for symbolic computations branch, master, updated. release_1-4-0-644-gf2051c35 Message-ID: <20191007203500.64AB7D814F2@cebix.net> 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 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 From git at ginac.de Mon Oct 7 22:35:53 2019 From: git at ginac.de (Richard B. Kreckel) Date: Mon, 7 Oct 2019 22:35:53 +0200 (CEST) Subject: [GiNaC-devel] [SCM] GiNaC -- a C++ library for symbolic computations tag, release_1-7-8, created. release_1-4-0-644-gf2051c35 Message-ID: <20191007203553.CF84FD8037D@cebix.net> 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 Date: Mon Oct 7 22:23:54 2019 +0200 Finalize 1.7.8 release. ----------------------------------------------------------------------- hooks/post-receive -- GiNaC -- a C++ library for symbolic computations From kreckel at in.terlu.de Mon Oct 7 22:43:32 2019 From: kreckel at in.terlu.de (Richard B. Kreckel) Date: Mon, 7 Oct 2019 22:43:32 +0200 Subject: [GiNaC-devel] Release 1.7.8 Message-ID: <8997c481-799a-0178-8c2b-6e5a122f9779@in.terlu.de> 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 From kisilv at maths.leeds.ac.uk Mon Oct 14 16:57:23 2019 From: kisilv at maths.leeds.ac.uk (Vladimir V. Kisil) Date: Mon, 14 Oct 2019 15:57:23 +0100 Subject: [GiNaC-devel] Power laws Message-ID: <23527.1571065043@math-pc2069.leeds.ac.uk> Dear All, I want to celebrate the 10th anniversary of this patch https://www.ginac.de/pipermail/ginac-devel/2009-October/001675.html by its re-submission. Since it was not objected since the original submission by anyone, it may be the time now to add this basic calculus-textbook rule to GiNaC. Best wishes, Vladimir -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Power-law-for-exponent.patch Type: text/x-diff Size: 1538 bytes Desc: GiNaC patch URL: From kreckel at in.terlu.de Tue Oct 15 09:23:21 2019 From: kreckel at in.terlu.de (Richard B. Kreckel) Date: Tue, 15 Oct 2019 09:23:21 +0200 Subject: [GiNaC-devel] Power laws In-Reply-To: <23527.1571065043@math-pc2069.leeds.ac.uk> References: <23527.1571065043@math-pc2069.leeds.ac.uk> Message-ID: Dear Vladimir, On 10/14/19 4:57 PM, Vladimir V. Kisil wrote: > I want to celebrate the 10th anniversary of this patch > > https://www.ginac.de/pipermail/ginac-devel/2009-October/001675.html > > by its re-submission. Since it was not objected since the original > submission by anyone, it may be the time now to add this > basic calculus-textbook rule to GiNaC. Well, after celebrating this patch, we should discuss it breaking check/exam_paranoia.cpp:217. That particular check has nothing to do with the exp() function, so we could re-write it in terms of Li2() or some other function and be done with it. But Fran?ois Maltey objected about exp(x)/exp(x) not eval'ing to 1 any more: https://www.ginac.de/pipermail/ginac-devel/2009-October/001680.html And, somehow, that should be addressed, I guess. I propose writing generic functions outside the automatic eval system along these lines https://www.ginac.de/FAQ.html#treetraverse searching for common arguments of exp() which may be combined. Would you like to venture? -richy. From kisilv at maths.leeds.ac.uk Tue Oct 15 10:06:44 2019 From: kisilv at maths.leeds.ac.uk (Vladimir V. Kisil) Date: Tue, 15 Oct 2019 09:06:44 +0100 Subject: [GiNaC-devel] Power laws In-Reply-To: References: <23527.1571065043@math-pc2069.leeds.ac.uk> Message-ID: <11855.1571126804@math-pc2069.leeds.ac.uk> Dear Richard, Thanks for reminding me the exp(x)/exp(x) cancellation and other issues. I am going to look on all of this together, but it will take some time (hopefully not another 10 years). Best wishes, Vladimir -- 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 >>>>> On Tue, 15 Oct 2019 09:23:21 +0200, "Richard B. Kreckel" said: RK> Dear Vladimir, On 10/14/19 4:57 PM, Vladimir V. Kisil wrote: >> I want to celebrate the 10th anniversary of this patch >> >> https://www.ginac.de/pipermail/ginac-devel/2009-October/001675.html >> >> by its re-submission. Since it was not objected since the >> original submission by anyone, it may be the time now to add this >> basic calculus-textbook rule to GiNaC. RK> Well, after celebrating this patch, we should discuss it RK> breaking check/exam_paranoia.cpp:217. RK> That particular check has nothing to do with the exp() function, RK> so we could re-write it in terms of Li2() or some other function RK> and be done with it. RK> But Fran?ois Maltey objected about exp(x)/exp(x) not eval'ing to RK> 1 any more: RK> https://www.ginac.de/pipermail/ginac-devel/2009-October/001680.html RK> And, somehow, that should be addressed, I guess. I propose RK> writing generic functions outside the automatic eval system RK> along these lines https://www.ginac.de/FAQ.html#treetraverse RK> searching for common arguments of exp() which may be RK> combined. Would you like to venture? RK> -richy. _______________________________________________ RK> GiNaC-devel mailing list GiNaC-devel at ginac.de RK> https://www.cebix.net/mailman/listinfo/ginac-devel From kisilv at maths.leeds.ac.uk Tue Oct 15 15:18:03 2019 From: kisilv at maths.leeds.ac.uk (Vladimir V. Kisil) Date: Tue, 15 Oct 2019 14:18:03 +0100 Subject: [GiNaC-devel] Power laws In-Reply-To: References: <23527.1571065043@math-pc2069.leeds.ac.uk> Message-ID: <21901.1571145483@math-pc2069.leeds.ac.uk> Dear Richard, >>>>> On Tue, 15 Oct 2019 09:23:21 +0200, "Richard B. Kreckel" said: RK> Well, after celebrating this patch, we should discuss it RK> breaking check/exam_paranoia.cpp:217. RK> That particular check has nothing to do with the exp() function, RK> so we could re-write it in terms of Li2() or some other function RK> and be done with it. RK> But Fran?ois Maltey objected about exp(x)/exp(x) not eval'ing to RK> 1 any more: RK> https://www.ginac.de/pipermail/ginac-devel/2009-October/001680.html RK> And, somehow, that should be addressed, I guess. It seems that both mentioned issues are connected. I am attaching a revised patch which applies the law of exponents, but keeps exp(x)^(-1) as exp(x)^(-1). With this patch check/exam_paranoia.cpp (as well as all other checks) went well (at least on my computer.) RK> I propose RK> writing generic functions outside the automatic eval system RK> along these lines https://www.ginac.de/FAQ.html#treetraverse RK> searching for common arguments of exp() which may be RK> combined. Would you like to venture? I will keep thinking on implementation of the rule e^t * e^s = e^(t+s). At the moment, I am in a favour to make it a part of a more general mechanism which will allow a user to apply some specific transformations for particular functions on demand (beyond wildcard substitutions). So it will not be done with the automatic evaluation and will not slow down the traditional performance. May be it is worth to add some more properties like add_func(), mul_func(), ncmul_func() to complement the existing power_func()... Best wishes, Vladimir -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Power-law-for-exponent.patch Type: text/x-diff Size: 2000 bytes Desc: Power law for exponent revised patch URL: From richard.crozier at yahoo.co.uk Tue Oct 22 13:37:25 2019 From: richard.crozier at yahoo.co.uk (Richard Crozier) Date: Tue, 22 Oct 2019 12:37:25 +0100 Subject: [GiNaC-devel] Windows 64 Bit Build Message-ID: <4bc78d63-a03d-8081-ab52-658fe864c686@yahoo.co.uk> 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 From kemlath at googlemail.com Wed Oct 23 09:13:34 2019 From: kemlath at googlemail.com (Kemlath Orcslayer) Date: Wed, 23 Oct 2019 09:13:34 +0200 Subject: [GiNaC-devel] Windows 64 Bit Build In-Reply-To: <4bc78d63-a03d-8081-ab52-658fe864c686@yahoo.co.uk> References: <4bc78d63-a03d-8081-ab52-658fe864c686@yahoo.co.uk> Message-ID: <78F47431-FBA3-4CE7-8E17-4ECCE9FB3E82@googlemail.com> Dear Richard, There are quite some incompatibilities between data type lengths under UNIX and Windows therefore the standard CLN branch does not work under windows. I was able to port the current GiNaC to windows using CLN from "https://github.com/jrheinlaender/ginac? If you want I have a complete GiNaC + CLN (no gmp no ams) + working example using a CMake based build system. Its not on git since the GiNaC part is slightly modified and has some extensions for faster serialisation that I use under MPI for broadcasting. Let me know if you?re interested Klaus > On 22. Oct 2019, at 13:37, Richard Crozier via GiNaC-devel wrote: > > 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 > > > > > _______________________________________________ > GiNaC-devel mailing list > GiNaC-devel at ginac.de > https://www.cebix.net/mailman/listinfo/ginac-devel From richard.crozier at yahoo.co.uk Wed Oct 23 11:41:45 2019 From: richard.crozier at yahoo.co.uk (Richard Crozier) Date: Wed, 23 Oct 2019 10:41:45 +0100 Subject: [GiNaC-devel] Windows 64 Bit Build In-Reply-To: <78F47431-FBA3-4CE7-8E17-4ECCE9FB3E82@googlemail.com> References: <4bc78d63-a03d-8081-ab52-658fe864c686@yahoo.co.uk> <78F47431-FBA3-4CE7-8E17-4ECCE9FB3E82@googlemail.com> Message-ID: Hi Klaus, I'm certainly interested, you might find that using MXE makes cross-compilation from Linux very easy, for example the dependency gmp is already available in MXE, so I was able to build the CLN w64 github repository with gmp. In fact no changes are required for the GiNaC or CLN build system, all that is required is that the sources can compile under mingw32-w64. If you are happy to share the code though, you could upload it here: https://cloud.reoptimizesystems.com/nextcloud/index.php/s/TEB9GaPbJydQQc2 My preference would of course be that the upstream mainline GiNaC sources can compile under mingw32-w64. It's worth mentioning that my ultimate goal is to build MBDyn (see www.mbdyn.org) which uses GiNaC if it is available for an optional component. I have this build working but without the GiNaC part. What is ams by the way, some internet searching didn't turn up anything obvious? Thanks, Richard On 23/10/2019 08:13, Kemlath Orcslayer via GiNaC-devel wrote: > Dear Richard, > > There are quite some incompatibilities between data type lengths under UNIX and Windows therefore the standard CLN branch does not work under windows. > I was able to port the current GiNaC to windows using CLN from "https://github.com/jrheinlaender/ginac??? > > If you want I have a complete GiNaC + CLN (no gmp no ams) + working example using a CMake based build system. > Its not on git since the GiNaC part is slightly modified and has some extensions for faster serialisation that I use under MPI for broadcasting. > > Let me know if you???re interested > > Klaus > >> On 22. Oct 2019, at 13:37, Richard Crozier via GiNaC-devel wrote: >> >> 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 >> >> >> >> >> _______________________________________________ >> GiNaC-devel mailing list >> GiNaC-devel at ginac.de >> https://www.cebix.net/mailman/listinfo/ginac-devel > > _______________________________________________ > GiNaC-devel mailing list > GiNaC-devel at ginac.de > https://www.cebix.net/mailman/listinfo/ginac-devel >