polylogarithms

[Beliavsky]

Are polylogarithms a suitable topic for stdlib, or are they too specialized?

The polylogarithm repo, MIT licensed, "provides C, C++ and Fortran implementations of various polylogarithms, including the real and complex dilogarithm, trilogarithm, and standard Clausen functions. The implementations have been fully tested against the literature and many other implementations and are highly optimized for fast numerical evaluation.

The package has no external dependencies, except for the C/C++/Fortran standard libraries. The implementations of the individual polylogarithm functions are distributed among different source code files, so individual source code files can be easily extracted and incorporated into existing projects."

Looking at the file Li2.f90, some possible changes to the code are as follows: (1) Variables are declared double precision, which one would replace with a real with a kind.
(2) Functions should be declared elemental when possible. (3) Modern comparison operations such == should be used instead of .eq. (4) Modules are not used, and the constant pi is defined in each function instead of at the module level. Same for implicit none. (5) Argument intents are not given, but usually there is only a single intent(in) argument. (6) (//) rather than [] is used in array constructors.

[arjenmarkus]

Just my opinion, but I think these functions are rather specialised, That does not mean the package could not become part of the fpm registry though.

Op vr 20 aug. 2021 om 18:43 schreef Beliavsky @.***>:

Are polylogarithms are suitable topic for stdlib, or are they too specialized?

The polylogarithm https://github.com/Expander/polylogarithm repo, MIT licensed, "provides C, C++ and Fortran implementations of various polylogarithms, including the real and complex dilogarithm, trilogarithm, and standard Clausen functions. The implementations have been fully tested against the literature and many other implementations and are highly optimized for fast numerical evaluation.

The package has no external dependencies, except for the C/C++/Fortran standard libraries. The implementations of the individual polylogarithm functions are distributed among different source code files, so individual source code files can be easily extracted and incorporated into existing projects."

Possible changes to the code: (1) Variables are declared double precision, which one would replace with a real with a kind. (2) Functions should be declared elemental when possible. (3) Modern comparison operations such == should be used instead of .eq. (4) Modules are not used, and the constant pi is defined in each function instead of at the module level. Same for implicit none. (5) Argument intents are not given, but usually there is only a single intent(in) argument. (6) (//) rather than [] is used in array constructors.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/fortran-lang/stdlib/issues/490, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAN6YR6EDSFLAFFXW2IHEZ3T52AZXANCNFSM5CQVBLSA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email .

[milancurcic]

I've never used them. Does anybody else here use them, in any language? What are polylogarithms useful for?

[Romendakil]

Polylogarithms are used in different fields of theoretical physics, particularly in theoretical particle physics and in theoretical condensed matter physics.

[nshaffer]

I've used polylogarithms extensively in the form of Fermi/Bose integrals for applications in quantum statistical mechanics. I regularly need integer and half-integer orders and real-valued arguments. Sometimes I also need the incomplete integrals, and sometimes I need high orders. The linked package has only integer orders 2 through 6. There are also algorithmic and floating-point issues with using polylogarithms to compute the Fermi/Dirac integrals. So I personally would not find the linked package helpful as-is and would need to find or write a separate package.

I suspect that the various applications of polylogarithms are different enough in their numerical requirements that it makes sense for them to live as separate packages.

[Beliavsky]

There appears to be a consensus that stdlib does not need polylogarithms. Is there an official way to mark this issue as rejected, or should I just close it?