GiNaC and polylogarithms

[Emanuele Bagnaschi]

Hi,
I'm a student of physics at the University of Milan (Italy), I was
recently introduced to harmonic and multiple polylogarithms and their
respective numerical evaluation methods.
I was also asked to look at the implementations of these algorithms in
GiNaC and, if possible, to improve the capabilities of this library.
By testing the functions already provided and by reading the
documentation I think I found a few things which are missing - correct
me if I'm wrong and these functionalities are already implemented or are simply unneeded.

First, G-functions currently evaluate numerically only for real
arguments y >= 0.
Secondly, in the tutorial is written that there's no support
for compiling expressions containing polylogarithms to C function pointers.
Finally, I see that there are some "TODO" comments in inifcns_nsdsums.cpp which describe missing features.

I'm also open to any other suggestions.
All comments are welcome.

Best regards
--
Emanuele A. Bagnaschi
_______________________________________________
GiNaC-devel mailing list
GiNaC-devel@...
https://www.cebix.net/mailman/listinfo/ginac-devel

[Jens Vollinga]

Hi,

sorry for the late reply.

Emanuele Bagnaschi schrieb:
> First, G-functions currently evaluate numerically only for real
> arguments y >= 0.

yes. But I have my doubts that "improving" this is really helpful for
practice.

> Secondly, in the tutorial is written that there's no support
> for compiling expressions containing polylogarithms to C function pointers.

True. This is badly missing. GiNaC should be able to generate a C
function that numerically evaluates a specific polylog in double
precision and whose name would be used in expression output. One reason
for not having implemented this yet is a principle problem of the code,
see below.

> Finally, I see that there are some "TODO" comments in inifcns_nsdsums.cpp which describe missing features.

Yes, but a lot of them are not that urgent, I think.

> I'm also open to any other suggestions.
> All comments are welcome.

Two more issues (which are the most urgent in this):

- Multiple polylogs with roots of unity as arguments (x1,x2,...) produce
for certain weights (m1,m2,...) wrong numeric results. There is still a
bug in the transformations. I would have to look a while for the
details. But while it is probably of no consequence for physics
applications, it is still a bad bug and needs to be fixed.

- The code is badly written. It mixes purely algebraic operations
(transformations) with numerics while using a (prematurely ...)
optimized representation of the arguments. This had and has three
consequences: bugs like above are very hard to catch, generating C
functions for compiled expressions is very difficult because the formula
  used in the end for the numerics is not available to the outside as a
whole (i.e. other functions managing the expression compilation), and
thirdly the functionality of just asking a polylog what its so and so
transformation would yield is not available to the user (there are other
nice math packages that offer this).

Regards,
Jens
_______________________________________________
GiNaC-devel mailing list
GiNaC-devel@...
https://www.cebix.net/mailman/listinfo/ginac-devel

[Emanuele Bagnaschi]

On 21:32 Tue 06 Oct     , Jens Vollinga wrote:
> Emanuele Bagnaschi schrieb:
> >First, G-functions currently evaluate numerically only for real
> >arguments y >= 0.
>
> yes. But I have my doubts that "improving" this is really helpful
> for practice.

I find your comment extremely interesting, since I was specifically
asked to look how to evaluate G-functions in the complex field.  Do you
think that the extension is naive because of the "scaling relation"?
Or there is something else behind your comment?

>
> [...]
>

I see that there is really a lot of work to do but I'm willing to
contribute to this project and improve the status of GiNaC with this
regard. I'm really interested, even at the personal level. In fact
I've searched for years for an interesting open source project to
start contributing to.

However I won't be free to focus on this matter at least until the
21st of October, due to some major university duties. In the meanwhile
I will try to get acquainted with the existing GiNaC code.

Best regards.
--
Emanuele A. Bagnaschi
_______________________________________________
GiNaC-devel mailing list
GiNaC-devel@...
https://www.cebix.net/mailman/listinfo/ginac-devel