Doctests for: fix polylog evalf

[rws]

The polylog function (from Pynac) treats 1.0 like 1 and does not immediately evalf with some numeric arguments.

sage: polylog(2,1)
1/6*pi^2
sage: polylog(2.,1)
1.64493406684823
sage: polylog(2,1.0)
1/6*pi^2
sage: polylog(2,0.9)
polylog(2, 0.900000000000000)
sage: _.n()
TypeError: cannot evaluate symbolic expression numerically

What makes polylog different is that the Sage polylog has no special value logic and calls Pynac's Li_eval for everything. This handles special values (incorrectly if an arg is FP) and sends everything else back with .hold(). So you need N() to get FP results that are not special. With FP Pynac is called which then calls Sage/mpmath. But this then bombs with FP args.

[paulmasson]

Ralf, there was a typo in the description of #21034 pointing to #18368 rather than this ticket.

I'm finding this behavior odd:

sage: polylog(2,.9999999999999999)
1.64493406684822
sage: polylog(2,1.)
NaN - NaN*I

This doesn't look fixed upstream to me: evalf needs to return a numeric value.

The doctest in functions/log.py captures the current behavior, but needs to be updated before this ticket can be closed.

[rws]

Polylog has a branch point/discontinuity at arguments (2,1). Anyway, we're just taking what arb is giving us:

sage: RBF=ComplexBallField(53)
sage: RBF(1.5).polylog(RBF(2.5))
[2.27833425640 +/- 2.25e-12] + [-0.61016023975 +/- 3.09e-12]*I
sage: RBF(.99999999).polylog(RBF(2.))
[1.6449338726414 +/- 9.23e-14] + [+/- 2.46e-13]*I
sage: RBF(1.).polylog(RBF(2.))
nan + nan*I
sage: RBF(1.00000001).polylog(RBF(2.))
[1.644934261055 +/- 1.08e-13] + [-3.1416e-8 +/- 3.19e-13]*I
sage: polylog(2,1)
1/6*pi^2

This is very sensible because if you need the exact value say so, and if you need an inexact value to 53 (or any) digits the result cannot be given in that precision so it's NaN. I'll concede that, similar to #19439 it may be desired to return the symbolic NaN.

[rws]

Replying to paulmasson:

I'm finding this behavior odd:

sage: polylog(2,1.)
NaN - NaN*I

This doesn't look fixed upstream to me: evalf needs to return a numeric value.

Evalf does return a numeric value, too:

sage: polylog(2,1.0).n()
NaN - NaN*I
sage: type(_)
<type 'sage.rings.complex_number.ComplexNumber'>

so, together with my previous answer I think this ticket can be closed.

[rws]

That was badly mistyped and misinterpreted by me, so back to the issue.

[rws]

Note also

sage: polylog(3,RBF(1.1))      # there is a polylog RBF member!
1.37625299668538 - 0.0142691615444952*I
sage: dilog(RBF(1.1))
1.96199910130557 - 0.299425760685590*I

[rws]

I believe this is fixed in Pynac master. The tests now also include ball field elements and all open issues from #19906.

---

New commits:

​5e182f3

18386: doctest fix for dilog/polylog numerics

[rws]

New commits:

​51aeae3

18386: doctest dilog/polylog fixes

[rws]

Fails tests with reduced precision.

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​074034a

Merge branch 'develop' into t/18386/18386-2

[rws]

We depend on #23077 and pynac-0.7.8 for improved handling of complex floats.

[rws]

Now that all dependencies are merged, let the patchbots test it and please review.

[jhpalmieri]

See #23565 for some changes to the behavior of polylog. Are those changes improvements?

[dimpase]

The biggest mystery here to me is how pynac is being able to use arb...

[dimpase]

the doctests added here, with correct (no NaNs!) outputs, are being added to #23565

[rws]

Replying to dimpase:

The biggest mystery here to me is how pynac is being able to use arb...

Pynac calls Sage's arb interface via the Python C API.

[dimpase]

Replying to rws:

Replying to dimpase:

The biggest mystery here to me is how pynac is being able to use arb...

Pynac calls Sage's arb interface via the Python C API.

I see, thanks, this explains why libpynac is not linked to libarb, contrary to what one would expect.

[fbissey]

Just rebasing. Nothing changed.

---

New commits:

​59d4b29

Merge branch 'develop' into 18386-2