Unreliable evaluation SR -> RealBallField for the erf function

[videlec]

sage: R = RealBallField(128)
sage: C = ComplexBallField(128)
sage: C(5).erf()    # direct arb evaluation
[0.99999999999846254020557196514981165651 +/- 7.33e-39]
sage: R(erf(5))     # conversion SR -> arb
[0.999999999998462563155499083222821354866 +/- 2.79e-41]

---

Initially appear in #27958. The following shows the difference between (certified) numerical integration using arb and symbolic integration followed by real ball evaluation. There is already an error on the 7th digit which shows that there is something very wrong.

sage: f = integral(exp(-x^2)*log(x), x, algorithm='sympy')
sage: f
1/2*sqrt(pi)*erf(x)*log(x) - x*hypergeometric((1/2, 1/2), (3/2, 3/2), -x^2)
sage: prec = 128
sage: R = RealBallField(prec)
sage: C = ComplexBallField(prec)
sage: a = 5; b = 6
sage: C.integral(lambda x,_: (-x*x).exp()*x.log(), a, b)
[2.21866269568217921271433463e-12 +/- 2.99e-39]
sage: R(f.subs(x=b)) - R(f.subs(x=a))
[2.2186641328845716165938996e-12 +/- 9.28e-38]

Note that both quantites persist in being different with more precision required

sage: prec = 2096
sage: R = RealBallField(prec)
sage: C = ComplexBallField(prec)
sage: C.integral(lambda x,_: (-x*x).exp()*x.log(), a, b)
[2.218662695682...e-12  +/- 6.58e-641]
sage: R(f.subs(x=b)) - R(f.subs(x=a))
[2.218664132884...e-12 +/- 6.50e-630]

And also that arb is perfectly able to evaluate erf and hypergeometric correctly

sage: def F(x, prec):
....:     R = RealBallField(prec)
....:     C = ComplexBallField(prec) 
....:     x = R(x)
....:     pi = R.pi()
....:     return 1/2 * pi.sqrt() * R(C(x).erf()) * x.log() - x * R(C(-x*x).hypergeometric((1/2,
....: 1/2), (3/2,3/2)))
sage: F(6, 256) - F(5, 256)
[2.218662695682179212714334629004026381551686783767108e-12 +/- 4.16e-64]

CC: @fchapoton @mezzarobba

Component: numerical

Author: Vincent Delecroix

Branch: b36b7b3

Reviewer: Frédéric Chapoton

Issue created by migration from https://trac.sagemath.org/ticket/28061

[videlec]

Branch: u/vdelecroix/28061

[videlec]

Commit: 4e55230

[videlec]

New commits:

fb5d367	28048: fix gap workspace name
4e55230	28061: reliable erf evaluation with real balls

[videlec]

Author: Vincent Delecroix

[sagetrac-git]

Changed commit from 4e55230 to b36b7b3

[sagetrac-git]

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

b36b7b3

28061: reliable erf evaluation with real balls

[fchapoton]

comment:5

ok, looks good. Merci

[fchapoton]

Reviewer: Frédéric Chapoton

[mezzarobba]

comment:6

I'm okay with this fix for now, but I wonder if the actual bug isn't that sage_to_mpath converts its input to a real number (essentially) unconditionally, instead of doing it only when there is a coercion.

[videlec]

comment:7

Replying to @mezzarobba:

I'm okay with this fix for now, but I wonder if the actual bug isn't that sage_to_mpath converts its input to a real number (essentially) unconditionally, instead of doing it only when there is a coercion.

This would already be better than the current situation as it would have raised an error with RBF(erf(5)). What you propose is a disjoint fix for a disjoint problem: I want RBF(erf(5)) to suceed not to fail.

[mezzarobba]

comment:8

Replying to @videlec:

What you propose is a disjoint fix for a disjoint problem: I want RBF(erf(5)) to suceed not to fail.

Yes, maybe. It's about the "unreliable evaluation" part of the problem; I agree that it's better if it works instead of raising an error (but real balls should eventually get an erf() method of their own...)

[videlec]

comment:9

Replying to @mezzarobba:

Replying to @videlec:

What you propose is a disjoint fix for a disjoint problem: I want RBF(erf(5)) to suceed not to fail.

Yes, maybe. It's about the "unreliable evaluation" part of the problem; I agree that it's better if it works instead of raising an error (but real balls should eventually get an erf() method of their own...)

You are right: we should automatically forward to complex balls the unavailable functions. See #28068

[vbraun]

Changed branch from u/vdelecroix/28061 to b36b7b3

[mezzarobba]

comment:11

Either this ticket didn't in fact fix the issue, or it reappeared since::

sage: ref = ComplexBallField(200)(5).erf().real()
sage: ref
[0.99999999999846254020557196514981165651461662110988194968528 +/- 5.48e-60]
sage: val = RealBallField(128)(erf(5)) # doctested, seee #28061
sage: val
[0.999999999998462540205571965149811656513 +/- 3.10e-40]
sage: val.overlaps(ref)
False

Do you remember if you checked the actual enclosure?

More about that shortly at #28517.

[mezzarobba]

Changed commit from b36b7b3 to none

[videlec]

comment:12

Are you on develop? Here is what I get

sage: ref = ComplexBallField(200)(5).erf().real()
sage: val = RealBallField(128)(erf(5))
sage: val.overlaps(ref)
True

[mezzarobba]

comment:13

Replying to @videlec:

Are you on develop? Here is what I get

sage: ref = ComplexBallField(200)(5).erf().real()
sage: val = RealBallField(128)(erf(5))
sage: val.overlaps(ref)
True

Interesting. You are right, I wasn't on develop, but I didn't expect the branch I was using to make a difference. I need to double-check. Thanks!