allow different algorithms for evaluating erf

[benjaminfjones]

In #1173 an mpmath numerical evaluator for erf was written by Douglas McNeil. This ticket proposes to save that code, incorporate it with the ability to pass an algorithm parameter to numerical_approx from #12289. We could support Pari, mpmath, and Maxima.

It would even be useful to see where Pari is faster.

Depends on #12289

CC: @sagetrac-dsm @kcrisman

Component: symbolics

Keywords: sd40.5 mpmath pari erf

Author: Benjamin Jones

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

[benjaminfjones]

Attachment: trac_13050_erf_mpmath_eval.patch.gz

add mpmath evaluation to erf

[benjaminfjones]

Changed dependencies from 12289 to #12289

[kcrisman]

comment:2

See comments at #11948 for why we probably want to do this or #1173 as soon as possible.

[jdemeyer]

comment:3

This looks like a duplicate of #1173 to me.

[kcrisman]

comment:4

This looks like a duplicate of #1173 to me.

I think that the point of this ticket was to do some of the things at #1173 more quickly, or using a different infrastructure, or something. Ben, what was the rationale exactly?

[kcrisman]

comment:5

I think that we can repurpose this ticket to adding the algorithm keyword here. Some good examples from #1173 (most were added in #13001):

Verify we're returning the appropriate zero:: 

            sage: erf(0) 
            0 
            sage: erf(0.0) 
            0.000000000000000 
            sage: erf(RealField(100)(0)) 
            0.00000000000000000000000000000 

set(erf(45*10**i).n() for i in range(10)) 

sage: CC(erf(ComplexField(1000)(2+3j))) 

[kcrisman]

Description changed:

--- 
+++ 
@@ -1,20 +1,3 @@
-In #1173 an mpmath numerical evaluator for `erf` was written by Douglas McNeil. This ticket proposes to save that code, incorporate it with the ability to pass an `algorithm` parameter to `numerical_approx` from #12289 and solve #13003 all in one go.
+In #1173 an mpmath numerical evaluator for `erf` was written by Douglas McNeil. This ticket proposes to save that code, incorporate it with the ability to pass an `algorithm` parameter to `numerical_approx` from #12289.  We could support Pari, mpmath, and Maxima.

-The mpmath evaluator is more robust than PARI, e.g. at large inputs. This is a good reason to switch the default numerical evaluation of `erf` to use mpmath like most of the rest of the new symbolic functions in Sage.
-
-In PARIs favor, it is faster for some inputs:
-
-```
-sage: timeit('erf(2).n()')
-625 loops, best of 3: 153 µs per loop
-sage: timeit("erf(2).n(algorithm='pari')")
-625 loops, best of 3: 135 µs per loop
-```
-but not always:
-
-```
-sage: timeit('erf(10^7).n()')
-625 loops, best of 3: 118 µs per loop
-sage: timeit('erf(10^7).n(algorithm="pari")')
-625 loops, best of 3: 132 µs per loop
-```
+It would even be useful to see where Pari is faster.