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: <ea6cbf1a-9dd2-75c4-6234-9fcce20aad91@in.terlu.de>

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
<https://in.terlu.de/~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: <ea6cbf1a-9dd2-75c4-6234-9fcce20aad91@in.terlu.de>
References: <30554.1569789314@math-pc2069.leeds.ac.uk>
 <ea6cbf1a-9dd2-75c4-6234-9fcce20aad91@in.terlu.de>
Message-ID: <18813.1569968514@math-pc2069.leeds.ac.uk>

>>>>> On Tue, 1 Oct 2019 23:55:00 +0200, "Richard B. Kreckel" <kreckel at in.terlu.de> 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 <kisilv at maths.leeds.ac.uk>
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 <kreckel at ginac.de>
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: <alpine.DEB.2.21.1910041458580.13784@yannicksurface>

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: <alpine.DEB.2.21.1910041458580.13784@yannicksurface>
References: <alpine.DEB.2.21.1910041458580.13784@yannicksurface>
Message-ID: <alpine.DEB.2.20.1910051138040.22128@iphths.Physik.Uni-Mainz.DE>


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: <http://www.ginac.de/pipermail/ginac-devel/attachments/20191005/acbf65e4/attachment.bin>

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: <alpine.DEB.2.20.1910051138040.22128@iphths.Physik.Uni-Mainz.DE>
References: <alpine.DEB.2.21.1910041458580.13784@yannicksurface>
 <alpine.DEB.2.20.1910051138040.22128@iphths.Physik.Uni-Mainz.DE>
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: <alpine.DEB.2.21.1910041458580.13784@yannicksurface>
 <alpine.DEB.2.20.1910051138040.22128@iphths.Physik.Uni-Mainz.DE>
 <113628ab-50f5-e969-f0d4-d2a57fb214c4@in.terlu.de>
Message-ID: <alpine.DEB.2.20.1910071230320.14797@iphths.Physik.Uni-Mainz.DE>


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 
<yannick.ulrich at psi.ch>."

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: <http://www.ginac.de/pipermail/ginac-devel/attachments/20191007/b22111d0/attachment.bin>

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 <weinzierl at 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 at 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


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 <kreckel at 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


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 <kreckel at 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


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
<https://in.terlu.de/~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: <http://www.ginac.de/pipermail/ginac-devel/attachments/20191014/d791e17e/attachment.bin>

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: <d9943bac-fa97-72b4-30fd-b1c089a17e36@in.terlu.de>

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: <d9943bac-fa97-72b4-30fd-b1c089a17e36@in.terlu.de>
References: <23527.1571065043@math-pc2069.leeds.ac.uk>
 <d9943bac-fa97-72b4-30fd-b1c089a17e36@in.terlu.de>
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" <kreckel at in.terlu.de> 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: <d9943bac-fa97-72b4-30fd-b1c089a17e36@in.terlu.de>
References: <23527.1571065043@math-pc2069.leeds.ac.uk>
 <d9943bac-fa97-72b4-30fd-b1c089a17e36@in.terlu.de>
Message-ID: <21901.1571145483@math-pc2069.leeds.ac.uk>

	Dear Richard,
>>>>> On Tue, 15 Oct 2019 09:23:21 +0200, "Richard B. Kreckel" <kreckel at in.terlu.de> 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: <http://www.ginac.de/pipermail/ginac-devel/attachments/20191015/592d941e/attachment.bin>

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 <ginac-devel at ginac.de> 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: <bfdb3217-6294-9aac-8d0d-64e45ae80467@yahoo.co.uk>

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 <ginac-devel at ginac.de> 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
>