Sage: Ticket #1173: implement numerical evaluation of erf at complex arguments via mpmath algorithm
https://trac.sagemath.org/ticket/1173
<p>
When implemented, this would work:
</p>
<pre class="wiki">sage: erf(2.0, algorithm='mpmath')
...
</pre><hr />
<p>
Apply patch <a class="attachment" href="https://trac.sagemath.org/attachment/ticket/1173/trac_1173_complex_erf_v3.patch" title="Attachment 'trac_1173_complex_erf_v3.patch' in Ticket #1173">trac_1173_complex_erf_v3.patch</a><a class="trac-rawlink" href="https://trac.sagemath.org/raw-attachment/ticket/1173/trac_1173_complex_erf_v3.patch" title="Download"></a> attached to this ticket to the Sage library.
</p>
en-usSagehttps://trac.sagemath.org/chrome/site/logo_sagemath_trac.png
https://trac.sagemath.org/ticket/1173
Trac 1.1.6wasThu, 15 Nov 2007 07:48:11 GMTdescription changed
https://trac.sagemath.org/ticket/1173#comment:1
https://trac.sagemath.org/ticket/1173#comment:1
<ul>
<li><strong>description</strong>
modified (<a href="/ticket/1173?action=diff&version=1">diff</a>)
</li>
</ul>
<p>
See also
<a class="ext-link" href="http://trac.sagemath.org/sage_trac/ticket/1174"><span class="icon"></span>http://trac.sagemath.org/sage_trac/ticket/1174</a>
</p>
TicketboothbyThu, 15 Nov 2007 08:05:03 GMT
https://trac.sagemath.org/ticket/1173#comment:2
https://trac.sagemath.org/ticket/1173#comment:2
<p>
The following has a GPL'd implementation in c:
</p>
<p>
<a class="ext-link" href="http://velveeta.che.wisc.edu/octave/lists/archive/octave-sources.1998/msg00032.html"><span class="icon"></span>http://velveeta.che.wisc.edu/octave/lists/archive/octave-sources.1998/msg00032.html</a>
</p>
TicketwasFri, 16 Nov 2007 18:03:43 GMT
https://trac.sagemath.org/ticket/1173#comment:3
https://trac.sagemath.org/ticket/1173#comment:3
<p>
This looks like the wya to go:
</p>
<p>
Josh Kantor:
</p>
<pre class="wiki">scipy has an error function that takes complex arguments
sage: import numpy, scipy
sage: from scipy import special
sage: j=numpy.complex(0,1)
sage: -j*float(sqrt(pi))*special.erf(2*j)/2
(16.45262776550727+0j)
Unfortunately numpy and sage's complex numbers are not compatible yet.
</pre>
TicketkcrismanWed, 30 Dec 2009 04:10:09 GMTupstream set
https://trac.sagemath.org/ticket/1173#comment:4
https://trac.sagemath.org/ticket/1173#comment:4
<ul>
<li><strong>upstream</strong>
set to <em>N/A</em>
</li>
</ul>
<p>
Numpy and Sage numbers now seem to work well, at least to some extent:
</p>
<pre class="wiki">sage: import numpy
sage: CC(numpy.complex(0,1))
1.00000000000000*I
sage: CC(numpy.complex(1,1))
1.00000000000000 + 1.00000000000000*I
sage: import scipy
sage: CC(scipy.special.erf(numpy.complex(1,1)))
1.31615128169795 + 0.190453469237835*I
</pre><p>
Is it time to wrap this now, two years after opening?
</p>
TicketAlexGhitzaSat, 02 Jan 2010 07:21:53 GMT
https://trac.sagemath.org/ticket/1173#comment:5
https://trac.sagemath.org/ticket/1173#comment:5
<p>
This can also be done by mpmath in arbitrary precision, see
</p>
<pre class="wiki">sage: import mpmath
sage: mpmath.erf?
</pre>
TicketkcrismanFri, 05 Feb 2010 20:01:40 GMT
https://trac.sagemath.org/ticket/1173#comment:6
https://trac.sagemath.org/ticket/1173#comment:6
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/1173#comment:5" title="Comment 5">AlexGhitza</a>:
</p>
<blockquote class="citation">
<p>
This can also be done by mpmath in arbitrary precision, see
</p>
<pre class="wiki">sage: import mpmath
sage: mpmath.erf?
</pre></blockquote>
<p>
And erf already has an _eval_f method, so maybe this could be changed to use mpmath? Even a loss in speed would be worth having the complex values. This could apply to error_fcn/erfc and others as well.
</p>
TicketkcrismanWed, 09 Jun 2010 01:39:44 GMT
https://trac.sagemath.org/ticket/1173#comment:7
https://trac.sagemath.org/ticket/1173#comment:7
<p>
Update - yes, we should definitely do this because of the complex values - just had a support request about not being able to do
</p>
<pre class="wiki">sage: integrate(sin(x^2),(x,2,6))
</pre><p>
and then use n() because of this (partly). See also <a class="closed ticket" href="https://trac.sagemath.org/ticket/9044" title="enhancement: Use mpmath for the erf() function (closed: duplicate)">#9044</a>.
</p>
TicketdsmThu, 24 Feb 2011 02:23:14 GMT
https://trac.sagemath.org/ticket/1173#comment:8
https://trac.sagemath.org/ticket/1173#comment:8
<p>
Okay, here's v0.prealpha0.0_1a of a patch which uses mpmath to get complex and arbitrary-precision behaviour for erf. (If it works out we can do error_fcn the same way, as noted by kcrisman).
</p>
<p>
Unfortunately it does introduce a speed regression:
</p>
<pre class="wiki"># 4.6.1, via pari
sage: timeit('float(erf(0))',number=1000) # must be float because 4.6.1 doesn't evaluate
1000 loops, best of 3: 109 µs per loop
sage: timeit('erf(0.1)',number=1000)
1000 loops, best of 3: 98.4 µs per loop
sage: timeit('erf(0.99)',number=1000)
1000 loops, best of 3: 98.5 µs per loop
# 4.6.2rc0 with patch
sage: timeit('erf(0)',number=1000)
1000 loops, best of 3: 68.3 µs per loop
sage: timeit('erf(0.1)',number=1000)
1000 loops, best of 3: 154 µs per loop
sage: timeit('erf(0.99)',number=1000)
1000 loops, best of 3: 165 µs per loop
</pre><p>
I attempted to fix this by using the old approach for the default precision, but it usually wound up being more expensive to do the tests. Someone with better speed-fu is encouraged to look at it. I haven't finished a long testall yet, so there's probably something somewhere which breaks, but here's the first attempt.
</p>
TicketdsmThu, 24 Feb 2011 02:26:52 GMTattachment set
https://trac.sagemath.org/ticket/1173
https://trac.sagemath.org/ticket/1173
<ul>
<li><strong>attachment</strong>
set to <em>trac_1173_add_complex_argument_erf.patch</em>
</li>
</ul>
TicketburcinThu, 24 Feb 2011 09:31:45 GMTstatus changed; author set
https://trac.sagemath.org/ticket/1173#comment:9
https://trac.sagemath.org/ticket/1173#comment:9
<ul>
<li><strong>status</strong>
changed from <em>new</em> to <em>needs_work</em>
</li>
<li><strong>author</strong>
set to <em>D. S. McNeil</em>
</li>
</ul>
<p>
The patch looks really good. The only problem I spotted after a quick reading is that the code blocks in the documentation should be after <code>::</code>. If the <code>TESTS</code> title is followed by text, you don't need the <code>::</code> after that.
</p>
<p>
AFAIR, mpmath now supports extracting the precision from the input type in Sage. It is not necessary to do this in each calling function any more. I don't have an example handy though.
</p>
<p>
For examples of fast methods to check the type of the input you can look at <code>sage/symbolic/pynac.pyx</code>. If you replace the <code>PY_TYPE_CHECK()</code> calls with <code>isinstance()</code> you should get a reasonable speed from python.
</p>
TicketdsmThu, 24 Feb 2011 09:57:55 GMT
https://trac.sagemath.org/ticket/1173#comment:10
https://trac.sagemath.org/ticket/1173#comment:10
<p>
@burcin:
</p>
<p>
Okay, so just to be clear: EXAMPLES and TESTS don't need trailing colons, whether double or single (although double does seem pretty common; is it okay to use it?), but I should definitely use a double colon after test descriptions, e.g.
</p>
<pre class="wiki">TESTS[::?]
Test that addition works::
sage: 2+3
5
Test that subtraction works::
sage: 3-2
1
</pre><p>
instead of
</p>
<pre class="wiki">TESTS::
Test that addition works:
sage: 2+3
5
Test that subtraction works:
sage: 3-2
1
</pre><p>
That's easy enough to fix. The other two will take a bit more work, but I'll see what I can find. Examples to pattern after are very welcome. <code>:-)</code>
</p>
TicketkcrismanThu, 24 Feb 2011 14:58:27 GMT
https://trac.sagemath.org/ticket/1173#comment:11
https://trac.sagemath.org/ticket/1173#comment:11
<p>
Usually we use one colon after <code>TEST</code> if there is text after it. The double colon needs to be before any actual test block. Also, doing <code>./sage -docbuild reference html</code> should give warning messages if it's wrong, if the file is in the reference manual (not all are).
</p>
TicketdsmFri, 25 Feb 2011 15:58:43 GMT
https://trac.sagemath.org/ticket/1173#comment:12
https://trac.sagemath.org/ticket/1173#comment:12
<p>
It seems like most of the speed decrease isn't due to anything I'm doing in _evalf_ but in _eval_, namely that I have one as opposed to the default <a class="missing wiki">BuiltinFunction?</a>._eval_. When I switch back to the default one I recover the old speeds, except that I no longer know how to get erf(0)=0 without wrapping the whole thing, and it has strange ideas about which arguments shouldn't be evaluated (such as <a class="missing wiki">ComplexField?</a>). I also didn't manage to find whatever mpmath magic will allow me to avoid the if isinstance(parent, Parent) and hasattr(parent, 'prec') or try: parent.prec() approach.
</p>
<p>
I'm at a loss for ways to proceed that don't involve modifying function.pyx, cythonizing, or wrapping the entire function to patch the holes.
</p>
TicketburcinFri, 17 Jun 2011 19:21:31 GMTreviewer set
https://trac.sagemath.org/ticket/1173#comment:13
https://trac.sagemath.org/ticket/1173#comment:13
<ul>
<li><strong>reviewer</strong>
set to <em>Burcin Erocal</em>
</li>
</ul>
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/1173#comment:12" title="Comment 12">dsm</a>:
</p>
<blockquote class="citation">
<p>
I'm at a loss for ways to proceed that don't involve modifying function.pyx, cythonizing, or wrapping the entire function to patch the holes.
</p>
</blockquote>
<p>
The speed problems can be solved by replacing the zero test <code>x == 0</code> with the example in <a class="closed ticket" href="https://trac.sagemath.org/ticket/11143#comment:17" title="Comment 17 for Ticket #11143">comment:17:ticket:11143</a>. The patch attached to that ticket also contains an example call to mpmath without the <code>prec</code> clutter. AFAICT, the only remaining issue with this ticket is the docstring formatting.
</p>
<p>
I'd be happy to give positive review to a patch with these changes... :)
</p>
TicketkcrismanFri, 17 Jun 2011 19:32:29 GMT
https://trac.sagemath.org/ticket/1173#comment:14
https://trac.sagemath.org/ticket/1173#comment:14
<p>
I'd say that it should also add one <em>very</em> minor additional doctest, for <code>erf(sqrt(2))</code>. That would allow us to close <a class="closed ticket" href="https://trac.sagemath.org/ticket/9044" title="enhancement: Use mpmath for the erf() function (closed: duplicate)">#9044</a> without not having a doctest. I realize that symbolic input is checked, but it would be nice to have for completeness and addressing specific user requests :)
</p>
TicketkcrismanMon, 20 Jun 2011 15:59:24 GMTwork_issues set
https://trac.sagemath.org/ticket/1173#comment:15
https://trac.sagemath.org/ticket/1173#comment:15
<ul>
<li><strong>work_issues</strong>
set to <em>add erf(sqrt(2)) and erf(45000).n(), formatting, perhaps speed</em>
</li>
</ul>
<p>
Here's another thing that should be added, reported by one of the PREP workshop participants before this patch was in:
</p>
<pre class="wiki">erf(4500).n()
1.0000000
erf(45000).n()
<boom>
</pre><p>
So Pari was not handling big number in erf before. With this patch, though
</p>
<pre class="wiki">sage: erf(4500).n()
1.00000000000000
sage: erf(45000).n()
1.00000000000000
sage: erf(4500000000).n()
1.00000000000000
</pre><p>
Since none of the doctests in the current patch seem to test "big" real input to erf, we should add this too.
</p>
TicketkcrismanMon, 01 Aug 2011 16:43:13 GMT
https://trac.sagemath.org/ticket/1173#comment:16
https://trac.sagemath.org/ticket/1173#comment:16
<p>
This should also solve <a class="closed ticket" href="https://trac.sagemath.org/ticket/11626" title="enhancement: make the error function work in arbitrary precision (closed: duplicate)">#11626</a>, I think?
</p>
TicketzimmermaThu, 18 Aug 2011 10:09:48 GMT
https://trac.sagemath.org/ticket/1173#comment:17
https://trac.sagemath.org/ticket/1173#comment:17
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/1173#comment:16" title="Comment 16">kcrisman</a>:
</p>
<blockquote class="citation">
<p>
This should also solve <a class="closed ticket" href="https://trac.sagemath.org/ticket/11626" title="enhancement: make the error function work in arbitrary precision (closed: duplicate)">#11626</a>, I think?
</p>
</blockquote>
<p>
right, thus <a class="closed ticket" href="https://trac.sagemath.org/ticket/11626" title="enhancement: make the error function work in arbitrary precision (closed: duplicate)">#11626</a> can be closed as soon as this ticket is closed
(or maybe right now?).
</p>
<p>
Douglas, can you implement the work issues in your patch?
</p>
<p>
Paul
</p>
TicketkcrismanThu, 18 Aug 2011 14:51:29 GMTdependencies set
https://trac.sagemath.org/ticket/1173#comment:18
https://trac.sagemath.org/ticket/1173#comment:18
<ul>
<li><strong>dependencies</strong>
set to <em>#11513</em>
</li>
</ul>
<p>
So, to review:
</p>
<ul><li>Burcin and I want a small formatting change so the doc would build correctly.
</li><li>Burcin wants the speed to be fixed using the thing referenced at <a class="closed ticket" href="https://trac.sagemath.org/ticket/11143" title="defect: define symbolic functions for exponential integrals (closed: fixed)">#11143</a>, using the patch at <a class="closed ticket" href="https://trac.sagemath.org/ticket/11513" title="enhancement: add is_trivial_zero() method to symbolic expressions (closed: fixed)">#11513</a>.
</li><li>I want a doctest that checks big numbers will work (as in <a class="ticket" href="https://trac.sagemath.org/ticket/1173#comment:15" title="Comment 15">comment 15</a>).
</li><li>Paul and I want a doctest for <a class="closed ticket" href="https://trac.sagemath.org/ticket/11626" title="enhancement: make the error function work in arbitrary precision (closed: duplicate)">#11626</a>, to verify it is fixed.
</li><li>Burcin <em>recommends</em> calling mpmath without prec as at <a class="closed ticket" href="https://trac.sagemath.org/ticket/11143" title="defect: define symbolic functions for exponential integrals (closed: fixed)">#11143</a>.
</li></ul><p>
This would make this depend on <a class="closed ticket" href="https://trac.sagemath.org/ticket/11513" title="enhancement: add is_trivial_zero() method to symbolic expressions (closed: fixed)">#11513</a>. I'm still a little skeptical on this; will we really not get any wrong answers with that?
</p>
TicketzimmermaThu, 18 Aug 2011 15:10:36 GMT
https://trac.sagemath.org/ticket/1173#comment:19
https://trac.sagemath.org/ticket/1173#comment:19
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/1173#comment:18" title="Comment 18">kcrisman</a>:
</p>
<blockquote class="citation">
<p>
So, to review:
</p>
<ul><li>I want a doctest that checks big numbers will work (as in <a class="ticket" href="https://trac.sagemath.org/ticket/1173#comment:15" title="Comment 15">comment 15</a>).
</li><li>Paul and I want a doctest for <a class="closed ticket" href="https://trac.sagemath.org/ticket/11626" title="enhancement: make the error function work in arbitrary precision (closed: duplicate)">#11626</a>, to verify it is fixed.
</li></ul></blockquote>
<p>
the current patch already contains examples with prec=100, both for real and complex numbers,
and thus is fine to me.
</p>
<p>
Paul
</p>
TicketkcrismanThu, 18 Aug 2011 15:31:37 GMT
https://trac.sagemath.org/ticket/1173#comment:20
https://trac.sagemath.org/ticket/1173#comment:20
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/1173#comment:19" title="Comment 19">zimmerma</a>:
</p>
<blockquote class="citation">
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/1173#comment:18" title="Comment 18">kcrisman</a>:
</p>
<blockquote class="citation">
<p>
So, to review:
</p>
<ul><li>I want a doctest that checks big numbers will work (as in <a class="ticket" href="https://trac.sagemath.org/ticket/1173#comment:15" title="Comment 15">comment 15</a>).
</li><li>Paul and I want a doctest for <a class="closed ticket" href="https://trac.sagemath.org/ticket/11626" title="enhancement: make the error function work in arbitrary precision (closed: duplicate)">#11626</a>, to verify it is fixed.
</li></ul></blockquote>
<p>
the current patch already contains examples with prec=100, both for real and complex numbers,
and thus is fine to me.
</p>
</blockquote>
<p>
Okay. I was thinking that because was not yet a test with the syntax <code>n(erf(2),100)</code>, which some users might find nicer than the other one, but of course they mean the same thing. I'll leave that up to Doug, then.
</p>
TicketkcrismanFri, 19 Aug 2011 14:15:17 GMTwork_issues changed
https://trac.sagemath.org/ticket/1173#comment:21
https://trac.sagemath.org/ticket/1173#comment:21
<ul>
<li><strong>work_issues</strong>
changed from <em>add erf(sqrt(2)) and erf(45000).n(), formatting, perhaps speed</em> to <em>add erf(sqrt(2)) and erf(45000).n(), formatting, speed</em>
</li>
</ul>
<p>
So:
</p>
<ul><li>Burcin and I want a small formatting change so the doc would build correctly.
</li><li>Burcin wants the speed to be fixed using the thing referenced at <a class="closed ticket" href="https://trac.sagemath.org/ticket/11143" title="defect: define symbolic functions for exponential integrals (closed: fixed)">#11143</a>, using the patch at <a class="closed ticket" href="https://trac.sagemath.org/ticket/11513" title="enhancement: add is_trivial_zero() method to symbolic expressions (closed: fixed)">#11513</a>.
</li><li>I want a doctest that checks big numbers like <code>erf(45000).n()</code> will work (as in <a class="ticket" href="https://trac.sagemath.org/ticket/1173#comment:15" title="Comment 15">comment 15</a>).
</li><li>I want a doctest for <code>erf(sqrt(2))</code> so <a class="closed ticket" href="https://trac.sagemath.org/ticket/9044" title="enhancement: Use mpmath for the erf() function (closed: duplicate)">#9044</a> can stay closed.
</li><li>Burcin <em>recommends</em> calling mpmath without prec as at <a class="closed ticket" href="https://trac.sagemath.org/ticket/11143" title="defect: define symbolic functions for exponential integrals (closed: fixed)">#11143</a>.
</li></ul>
TicketkcrismanTue, 25 Oct 2011 01:18:01 GMT
https://trac.sagemath.org/ticket/1173#comment:22
https://trac.sagemath.org/ticket/1173#comment:22
<p>
See also <a class="closed ticket" href="https://trac.sagemath.org/ticket/11948" title="defect: Fix numeric evaluation of error function (closed: fixed)">#11948</a>.
</p>
TicketddrakeTue, 25 Oct 2011 02:08:33 GMT
https://trac.sagemath.org/ticket/1173#comment:23
https://trac.sagemath.org/ticket/1173#comment:23
<p>
I ran into this problem (<a class="ext-link" href="https://groups.google.com/d/topic/sage-support/SNw_6mLFnrg/discussion"><span class="icon"></span>https://groups.google.com/d/topic/sage-support/SNw_6mLFnrg/discussion</a>) and this patch fixes it. This patch seems to have some issues with a speed regression and some doctests, but it does fix a problem that I have.
</p>
TicketdsmSat, 29 Oct 2011 00:55:06 GMT
https://trac.sagemath.org/ticket/1173#comment:24
https://trac.sagemath.org/ticket/1173#comment:24
<p>
</lurk>
</p>
<p>
Okay, I'm back. Is it worth finishing this patch or should we follow the <a class="closed ticket" href="https://trac.sagemath.org/ticket/11948" title="defect: Fix numeric evaluation of error function (closed: fixed)">#11948</a> path instead?
</p>
TicketkcrismanSat, 29 Oct 2011 02:14:37 GMT
https://trac.sagemath.org/ticket/1173#comment:25
https://trac.sagemath.org/ticket/1173#comment:25
<blockquote class="citation">
<p>
Okay, I'm back. Is it worth finishing this patch or should we follow the <a class="closed ticket" href="https://trac.sagemath.org/ticket/11948" title="defect: Fix numeric evaluation of error function (closed: fixed)">#11948</a> path instead?
</p>
</blockquote>
<p>
Go for it!
</p>
TicketdsmSat, 29 Oct 2011 20:17:26 GMT
https://trac.sagemath.org/ticket/1173#comment:26
https://trac.sagemath.org/ticket/1173#comment:26
<p>
Now I remember why I found this so frustrating. I rewrote the patch following -- plagiarizing is more like it! -- the pattern used in <a class="closed ticket" href="https://trac.sagemath.org/ticket/11143" title="defect: define symbolic functions for exponential integrals (closed: fixed)">#11143</a>, but the speed issue hasn't gone away.
</p>
<pre class="wiki">
# 4.7.1, OS X 10.6.8
sage: timeit('erf(0.1)',number=1000)
1000 loops, best of 3: 82.9 µs per loop
sage: timeit('erf(10.0)',number=1000)
1000 loops, best of 3: 72.8 µs per loop
sage: timeit('erf(100.0)',number=1000)
1000 loops, best of 3: 73.5 µs per loop
# 4.7.2 before patch
sage: timeit('erf(0.1)',number=1000)
1000 loops, best of 3: 69.4 µs per loop
sage: timeit('erf(10.0)',number=1000)
1000 loops, best of 3: 62.6 µs per loop
sage: timeit('erf(100.0)',number=1000)
1000 loops, best of 3: 62 µs per loop
# 4.7.2 after patch
sage: timeit('erf(0.1)',number=1000)
1000 loops, best of 3: 137 µs per loop
sage: timeit('erf(10.0)',number=1000)
1000 loops, best of 3: 116 µs per loop
sage: timeit('erf(100.0)',number=1000)
1000 loops, best of 3: 116 µs per loop
sage: import mpmath
sage: timeit('mpmath.erf(0.1)')
625 loops, best of 3: 95 µs per loop
sage: timeit('mpmath.erf(10.0)')
625 loops, best of 3: 75.4 µs per loop
sage: timeit('mpmath.erf(100.0)')
625 loops, best of 3: 76.2 µs per loop
</pre><p>
That is, there's about a factor of two penalty in speed for the standard case, but it's not because the underlying mpmath code is slow:
</p>
<pre class="wiki">sage: timeit('mpmath.erf(0.1r)')
625 loops, best of 3: 27.7 µs per loop
sage: timeit('mpmath.erf(10.0r)')
625 loops, best of 3: 9.85 µs per loop
sage: timeit('mpmath.erf(100.0r)')
625 loops, best of 3: 9.95 µs per loop
</pre><p>
In fact, mpmath isn't that much slower than MPFR:
</p>
<pre class="wiki">sage: z = RR(2); timeit('z.erf()')
625 loops, best of 3: 20 µs per loop
sage: z = 2.0r; timeit('mpmath.erf(z)')
625 loops, best of 3: 57.9 µs per loop
sage: timeit('erf(2.0)') # new code
625 loops, best of 3: 181 µs per loop
</pre><p>
So not much of the total time is spent actually doing any calculations: it's all overhead. :-( This affects <a class="closed ticket" href="https://trac.sagemath.org/ticket/11143" title="defect: define symbolic functions for exponential integrals (closed: fixed)">#11143</a> as well:
</p>
<pre class="wiki">sage: timeit('exp_integral_e1(2.0)')
625 loops, best of 3: 165 µs per loop
sage: z = exp_integral_e1(2); timeit('z.n()')
625 loops, best of 3: 143 µs per loop
sage: timeit('exponential_integral_1(2.0)')
625 loops, best of 3: 44.7 µs per loop
sage: timeit('mpmath.e1(2.0)')
625 loops, best of 3: 123 µs per loop
sage: timeit('mpmath.e1(2.0r)')
625 loops, best of 3: 51 µs per loop
</pre><p>
To wrap up:
</p>
<p>
(1) Both this patch and <a class="closed ticket" href="https://trac.sagemath.org/ticket/11143" title="defect: define symbolic functions for exponential integrals (closed: fixed)">#11143</a> suffer a significant slowdown relative to PARI, and have major overheads relative to calling mpmath. Some of that's unavoidable given the symbolic path, but ISTM we should be able to do better. Ideally there would be a reasonably efficient general special function implementation pattern, along the lines of what Benjamin used, that intermittent developers like me could be pointed to as a reference.
</p>
<p>
(2) In the case of erf and erfc, mpfr offers a very fast evaluation for real numbers, fast enough that it might be worth using as the default in those cases (although Python-level branching is slow in my experience, maybe slow enough to wash away the benefits). Once we settle on an approach for erf I'll do the same for erfc.
</p>
<p>
(3) Should I move this out of other.py to special.py, where the complementary error_fcn function lives now? It would seem a more natural location for it. We also have some unfortunate naming (erf and error_fcn) it might be worth addressing.
</p>
<p>
I don't have numbers for <a class="closed ticket" href="https://trac.sagemath.org/ticket/11948" title="defect: Fix numeric evaluation of error function (closed: fixed)">#11948</a> -- too many dependencies -- but it's probably considerably faster than this approach. I figure it's probably worth getting the <a class="closed ticket" href="https://trac.sagemath.org/ticket/11143" title="defect: define symbolic functions for exponential integrals (closed: fixed)">#11143</a> -style mpmath wrapper to be faster, though, even if we went <a class="closed ticket" href="https://trac.sagemath.org/ticket/11948" title="defect: Fix numeric evaluation of error function (closed: fixed)">#11948</a> instead for erf/erfc.
</p>
<p>
[There are a few doctest failures: "devel/sage/doc/en/bordeaux_2008/l_series.rst", which I think is unrelated; a timeout in devel/sage/sage/modules/free_module.py, again probably unrelated.]
</p>
TicketdsmSat, 29 Oct 2011 20:40:28 GMTattachment set
https://trac.sagemath.org/ticket/1173
https://trac.sagemath.org/ticket/1173
<ul>
<li><strong>attachment</strong>
set to <em>trac_1173_complex_erf_v2.patch</em>
</li>
</ul>
<p>
11143-style mpmath erf
</p>
TicketburcinSun, 30 Oct 2011 11:07:58 GMT
https://trac.sagemath.org/ticket/1173#comment:27
https://trac.sagemath.org/ticket/1173#comment:27
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/1173#comment:26" title="Comment 26">dsm</a>:
<snip>
</p>
<blockquote class="citation">
<p>
To wrap up:
</p>
<p>
(1) Both this patch and <a class="closed ticket" href="https://trac.sagemath.org/ticket/11143" title="defect: define symbolic functions for exponential integrals (closed: fixed)">#11143</a> suffer a significant slowdown relative to PARI, and have major overheads relative to calling mpmath. Some of that's unavoidable given the symbolic path, but ISTM we should be able to do better. Ideally there would be a reasonably efficient general special function implementation pattern, along the lines of what Benjamin used, that intermittent developers like me could be pointed to as a reference.
</p>
</blockquote>
<p>
I agree that we should do better. Note that the pattern you request is being developed in <a class="closed ticket" href="https://trac.sagemath.org/ticket/11143" title="defect: define symbolic functions for exponential integrals (closed: fixed)">#11143</a> and here. Even though pynac based symbolics was merged in Sage quite a while ago, it hasn't been used properly yet.
</p>
<p>
The code path to call symbolic functions is rather convoluted. This is inevitable since symbolic functions have to play well with many different subsystems, such as fast float, numpy, etc. But it should still be possible to reduce the overhead.
</p>
<p>
For <code>BuiltinFunction</code>s the code path for evaluation goes through <code>Function.__call__()</code> in <code>sage/symbolic/function.pyx</code>, then into pynac, then to the python method you define for <code>_eval_()</code>, if numeric evaluation is needed to <code>_evalf_()</code> later. Here, between the python and C++ code, conversion functions are called to wrap pynac objects in Expression instances or to remove these wrappers.
</p>
<p>
I believe most of the overhead comes from the <code>__call__()</code> method, then having to decide if the arguments are numeric in <code>_eval_()</code>, and checking if an argument is zero (<a class="closed ticket" href="https://trac.sagemath.org/ticket/11513" title="enhancement: add is_trivial_zero() method to symbolic expressions (closed: fixed)">#11513</a>).
</p>
<blockquote class="citation">
<p>
(2) In the case of erf and erfc, mpfr offers a very fast evaluation for real numbers, fast enough that it might be worth using as the default in those cases (although Python-level branching is slow in my experience, maybe slow enough to wash away the benefits). Once we settle on an approach for erf I'll do the same for erfc.
</p>
</blockquote>
<p>
MPFR should be the default numeric evaluation method if it is available. In general, it's better to let the types choose the numeric evaluation method. Most special functions in Sage first see if an object implements a method with the same name first and calls that. For instance <code>erf()</code> should call <code>.erf()</code> for element of <code>RR</code>.
</p>
<p>
I see that for subclasses of <code>GinacFunction</code> the <code>__call__()</code> method does this automatically. This is not used for other <code>BuiltinFunction</code>s though. It might make sense to move this method to <code>BuiltinFunction</code>. This would speed up most of the timings for real numbers above.
</p>
<p>
Unfortunately, floats would still go through the long path. Since these are used quite often in plotting, perhaps we should add a special case in <code>__call__()</code> to go directly to <code>_evalf_()</code> as well.
</p>
<p>
I made this change in <a class="attachment" href="https://trac.sagemath.org/attachment/ticket/1173/trac_1173-move_call.patch" title="Attachment 'trac_1173-move_call.patch' in Ticket #1173">attachment:trac_1173-move_call.patch</a><a class="trac-rawlink" href="https://trac.sagemath.org/raw-attachment/ticket/1173/trac_1173-move_call.patch" title="Download"></a>. Now I get:
</p>
<pre class="wiki">sage: t = RR(2.0)
sage: %timeit z = t.erf()
625 loops, best of 3: 16.9 µs per loop
sage: %timeit z = erf(t)
625 loops, best of 3: 18.2 µs per loop
</pre><p>
Performance for <code>float</code> is still pretty bad.
</p>
<pre class="wiki">sage: u = 2.0r
sage: %timeit z = erf(u)
625 loops, best of 3: 156 µs per loop
</pre><p>
I didn't check if this patch breaks anything.
</p>
<blockquote class="citation">
<p>
(3) Should I move this out of other.py to special.py, where the complementary error_fcn function lives now? It would seem a more natural location for it. We also have some unfortunate naming (erf and error_fcn) it might be worth addressing.
</p>
</blockquote>
<p>
I don't think there is a need to move this to <code>special.py</code>. That file is also overcrowded and needs serious cleanup. You could create a new file names <code>error_fn.py</code> if you think that's necessary.
</p>
<p>
What names do other systems use for these functions? AFAIK, <code>erf()</code> and <code>erfc()</code> are pretty much standard. I wonder where <code>error_fcn()</code> came from.
</p>
TicketburcinSun, 30 Oct 2011 11:11:04 GMTattachment set
https://trac.sagemath.org/ticket/1173
https://trac.sagemath.org/ticket/1173
<ul>
<li><strong>attachment</strong>
set to <em>trac_1173-move_call.patch</em>
</li>
</ul>
TicketdsmSun, 30 Oct 2011 21:27:58 GMT
https://trac.sagemath.org/ticket/1173#comment:28
https://trac.sagemath.org/ticket/1173#comment:28
<p>
Okay, this looks a bit better. With trac_1173-move_call.patch, trac_11885_v2.patch, trac_11513-is_numerically_zero.patch, and trac_1173_complex_erf_v3.patch:
</p>
<pre class="wiki">alpha3:
0.100000000000000 float 121 µs per loop
0.100000000000000 RDF 51.6 µs per loop
0.100000000000000 RR 61.2 µs per loop
0.100000000000000 RealField(100) 64.5 µs per loop
0.100000000000000 RealField(1000) 304 µs per loop
new:
0.100000000000000 float 49.3 µs per loop
0.100000000000000 RDF 773 ns per loop
0.100000000000000 RR 7.07 µs per loop
0.100000000000000 RealField(100) 10.6 µs per loop
0.100000000000000 RealField(1000) 248 µs per loop
0.100000000000000 complex 131 µs per loop
0.100000000000000 CDF 185 µs per loop
0.100000000000000 CC 254 µs per loop
0.100000000000000 ComplexField(100) 262 µs per loop
0.100000000000000 ComplexField(1000) 470 µs per loop
0.100000000000000*I complex 247 µs per loop
0.100000000000000*I CDF 389 µs per loop
0.100000000000000*I CC 405 µs per loop
0.100000000000000*I ComplexField(100) 470 µs per loop
0.100000000000000*I ComplexField(1000) 565 µs per loop
</pre><p>
Now not only is there no regression, we've improved. The speedups relative to alpha3 for reals are due to using the existing mpfr .erf()s instead of pari; float was special-cased through RDF. As I mentioned, I don't have the new pari, and that's probably faster than mpmath. But at least it's not killing me anymore.
</p>
<p>
There's a doctest failure in gamma_inc due to trac_1173-move_call.patch, I think-- formerly,
</p>
<pre class="wiki">sage: parent(gamma_inc(RDF(1),3))
Complex Field with 53 bits of precision
</pre><p>
but now
</p>
<pre class="wiki">sage: parent(gamma_inc(RDF(1),3))
Real Double Field
</pre><p>
but gamma_inc doesn't preserve types the way I'd have expected. Anyway, I think this is a step in the right direction.
</p>
TicketdsmSun, 30 Oct 2011 21:29:01 GMTattachment set
https://trac.sagemath.org/ticket/1173
https://trac.sagemath.org/ticket/1173
<ul>
<li><strong>attachment</strong>
set to <em>trac_1173_complex_erf_v3.patch</em>
</li>
</ul>
<p>
11143-style erf, use mpfr where possible
</p>
TicketkcrismanTue, 22 Nov 2011 01:46:30 GMT
https://trac.sagemath.org/ticket/1173#comment:29
https://trac.sagemath.org/ticket/1173#comment:29
<p>
Qs, as this is now official fodder for [wiki/days35.5/bugs Sage Days 35.5]:
</p>
<ul><li>What patches should be applied here?
</li><li>Are we ready for review? (I.e., are all work issues taken care of?)
</li><li>What's the status of <a class="closed ticket" href="https://trac.sagemath.org/ticket/11513" title="enhancement: add is_trivial_zero() method to symbolic expressions (closed: fixed)">#11513</a> with respect to this patch?
</li></ul><p>
Thanks!
</p>
TicketbenjaminfjonesFri, 16 Dec 2011 00:57:17 GMTcc set
https://trac.sagemath.org/ticket/1173#comment:30
https://trac.sagemath.org/ticket/1173#comment:30
<ul>
<li><strong>cc</strong>
<em>benjaminfjones</em> added
</li>
</ul>
TicketbenjaminfjonesFri, 16 Dec 2011 01:43:52 GMTreviewer changed
https://trac.sagemath.org/ticket/1173#comment:31
https://trac.sagemath.org/ticket/1173#comment:31
<ul>
<li><strong>reviewer</strong>
changed from <em>Burcin Erocal</em> to <em>Burcin Erocal, Benjamin Jones</em>
</li>
</ul>
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/1173#comment:29" title="Comment 29">kcrisman</a>:
</p>
<blockquote class="citation">
<p>
Qs, as this is now official fodder for [wiki/days35.5/bugs Sage Days 35.5]:
</p>
<ul><li>What patches should be applied here?
</li><li>Are we ready for review? (I.e., are all work issues taken care of?)
</li><li>What's the status of <a class="closed ticket" href="https://trac.sagemath.org/ticket/11513" title="enhancement: add is_trivial_zero() method to symbolic expressions (closed: fixed)">#11513</a> with respect to this patch?
</li></ul><p>
Thanks!
</p>
</blockquote>
<p>
I started to review the patch. Looks like:
</p>
<ul><li>The only dependency is <a class="closed ticket" href="https://trac.sagemath.org/ticket/11513" title="enhancement: add is_trivial_zero() method to symbolic expressions (closed: fixed)">#11513</a> which should be applied before <a class="ext-link" href="http://trac.sagemath.org/sage_trac/attachment/ticket/1173/trac_1173_complex_erf_v3.patch"><span class="icon"></span>trac_1173_complex_erf_v3.patch</a>
</li><li>All of the work issues are taken care of
</li><li><a class="closed ticket" href="https://trac.sagemath.org/ticket/11513" title="enhancement: add is_trivial_zero() method to symbolic expressions (closed: fixed)">#11513</a> hasn't changed since Burcin uploaded the initial draft patch. I don't have the expertise to work on it or else I would in support of the various tickets we've got now that depend on it.
</li></ul><p>
The patch trac_1173_complex_erf_v3.patch applies to 4.8.alpha3 cleanly (as does the patch at <a class="closed ticket" href="https://trac.sagemath.org/ticket/11513" title="enhancement: add is_trivial_zero() method to symbolic expressions (closed: fixed)">#11513</a>) and all doctests pass.
</p>
<p>
It also looks like the "move call" patch should be applied to speed things up after some doctests are fixed. I'd say this should go into a new ticket because the issue is independent of evaluation of erf() at complex inputs.
</p>
<p>
Positive review.
</p>
<p>
</p>
TicketkcrismanMon, 19 Dec 2011 17:59:07 GMT
https://trac.sagemath.org/ticket/1173#comment:32
https://trac.sagemath.org/ticket/1173#comment:32
<p>
Does this also take care of <a class="closed ticket" href="https://trac.sagemath.org/ticket/8983" title="enhancement: erf(0) should return 0 (closed: fixed)">#8983</a>?
</p>
TicketbenjaminfjonesMon, 19 Dec 2011 18:47:43 GMT
https://trac.sagemath.org/ticket/1173#comment:33
https://trac.sagemath.org/ticket/1173#comment:33
<p>
Yes, both of these doctests are in DSM's patch:
</p>
<pre class="wiki">sage: erf(0)
0
sage: solve(erf(x)==0,x)
[x == 0]
</pre>
TicketzimmermaSat, 24 Dec 2011 14:52:00 GMT
https://trac.sagemath.org/ticket/1173#comment:34
https://trac.sagemath.org/ticket/1173#comment:34
<p>
Benjamin or Burcin, please could you add in the description which patches have to be applied, and in which order?
</p>
<p>
Paul
</p>
TicketzimmermaSat, 24 Dec 2011 14:55:24 GMT
https://trac.sagemath.org/ticket/1173#comment:35
https://trac.sagemath.org/ticket/1173#comment:35
<p>
Benjamin, you gave a positive review in comment <a class="ticket" href="https://trac.sagemath.org/ticket/1173#comment:31" title="Comment 31">31</a> but forgot to change the status accordingly.
</p>
<p>
Paul
</p>
TicketbenjaminfjonesSat, 24 Dec 2011 16:09:55 GMTstatus, description changed
https://trac.sagemath.org/ticket/1173#comment:36
https://trac.sagemath.org/ticket/1173#comment:36
<ul>
<li><strong>status</strong>
changed from <em>needs_work</em> to <em>positive_review</em>
</li>
<li><strong>description</strong>
modified (<a href="/ticket/1173?action=diff&version=36">diff</a>)
</li>
</ul>
TicketbenjaminfjonesSat, 24 Dec 2011 16:11:07 GMT
https://trac.sagemath.org/ticket/1173#comment:37
https://trac.sagemath.org/ticket/1173#comment:37
<p>
Done. I was waiting to see if anyone else had comments or concerns before setting the status to positive review, but looks like it's been long enough. I've done some work on <a class="closed ticket" href="https://trac.sagemath.org/ticket/11513" title="enhancement: add is_trivial_zero() method to symbolic expressions (closed: fixed)">#11513</a> in the last few days. I'll update there the next change I get.
</p>
TicketjdemeyerMon, 26 Dec 2011 09:33:21 GMTmilestone changed; work_issues deleted
https://trac.sagemath.org/ticket/1173#comment:38
https://trac.sagemath.org/ticket/1173#comment:38
<ul>
<li><strong>work_issues</strong>
<em>add erf(sqrt(2)) and erf(45000).n(), formatting, speed</em> deleted
</li>
<li><strong>milestone</strong>
changed from <em>sage-4.8</em> to <em>sage-5.0</em>
</li>
</ul>
<p>
This obviously conflicts with <a class="closed ticket" href="https://trac.sagemath.org/ticket/11948" title="defect: Fix numeric evaluation of error function (closed: fixed)">#11948</a>
</p>
TicketjdemeyerMon, 26 Dec 2011 09:33:50 GMTmilestone changed
https://trac.sagemath.org/ticket/1173#comment:39
https://trac.sagemath.org/ticket/1173#comment:39
<ul>
<li><strong>milestone</strong>
changed from <em>sage-5.0</em> to <em>sage-pending</em>
</li>
</ul>
TicketvbraunSun, 08 Jan 2012 18:38:26 GMT
https://trac.sagemath.org/ticket/1173#comment:40
https://trac.sagemath.org/ticket/1173#comment:40
<p>
Fixed in <a class="closed ticket" href="https://trac.sagemath.org/ticket/11948" title="defect: Fix numeric evaluation of error function (closed: fixed)">#11948</a>, so I the release manager should close this ticket as duplicate.
</p>
TicketkcrismanSun, 08 Jan 2012 20:38:50 GMT
https://trac.sagemath.org/ticket/1173#comment:41
https://trac.sagemath.org/ticket/1173#comment:41
<p>
Though perhaps we should check that all doctests are still included!
</p>
TicketjdemeyerMon, 09 Jan 2012 13:07:57 GMT
https://trac.sagemath.org/ticket/1173#comment:42
https://trac.sagemath.org/ticket/1173#comment:42
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/1173#comment:41" title="Comment 41">kcrisman</a>:
</p>
<blockquote class="citation">
<p>
Though perhaps we should check that all doctests are still included!
</p>
</blockquote>
<p>
Which is certainly not the case. In fact, this ticket here does more than simply implementing <code>erf()</code> for complex arguments.
</p>
TicketbenjaminfjonesMon, 09 Jan 2012 15:44:28 GMTkeywords set
https://trac.sagemath.org/ticket/1173#comment:43
https://trac.sagemath.org/ticket/1173#comment:43
<ul>
<li><strong>keywords</strong>
<em>sd35.5</em> added
</li>
</ul>
<p>
It seems to me that both PARI and mpmath should be an option via an <code>algorithm</code> keyword argument. I'm at Sage Days 35.5 working on this stuff, so one thing I could do is take the improvements in this ticket and rebase them on top of <a class="closed ticket" href="https://trac.sagemath.org/ticket/11948" title="defect: Fix numeric evaluation of error function (closed: fixed)">#11948</a> which has been merged in 4.8.alpha6. If folks agree, I guess that should be a new ticket and this one could be closed.
</p>
TicketkcrismanMon, 09 Jan 2012 16:03:38 GMT
https://trac.sagemath.org/ticket/1173#comment:44
https://trac.sagemath.org/ticket/1173#comment:44
<p>
Sounds good, as long as you keep any "good stuff" from this ticket.
</p>
TicketzimmermaMon, 09 Jan 2012 16:24:15 GMT
https://trac.sagemath.org/ticket/1173#comment:45
https://trac.sagemath.org/ticket/1173#comment:45
<p>
Hi Benjamin,
</p>
<p>
note that 4.8.rc1 is already out, should be newer than 4.8.alpha6.
</p>
<p>
Paul (at SD 35.5 too, but remotely)
</p>
TicketbenjaminfjonesMon, 09 Jan 2012 16:31:59 GMT
https://trac.sagemath.org/ticket/1173#comment:46
https://trac.sagemath.org/ticket/1173#comment:46
<p>
Hi Paul, are you on IRC? We're using the #sagemath-days channel. It looks like the 4.8.rc1 is still under construction according to the README. I'm looking in <a class="ext-link" href="http://sage.math.washington.edu/home/release/sage-4.8.rc1/"><span class="icon"></span>http://sage.math.washington.edu/home/release/sage-4.8.rc1/</a>
</p>
TicketzimmermaMon, 09 Jan 2012 16:44:31 GMT
https://trac.sagemath.org/ticket/1173#comment:47
https://trac.sagemath.org/ticket/1173#comment:47
<p>
no I'm not on IRC. Ok, then I'll use 4.8.alpha6 instead.
</p>
<p>
Paul
</p>
TicketjdemeyerMon, 09 Jan 2012 20:03:12 GMT
https://trac.sagemath.org/ticket/1173#comment:48
https://trac.sagemath.org/ticket/1173#comment:48
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/1173#comment:45" title="Comment 45">zimmerma</a>:
</p>
<blockquote class="citation">
<p>
Hi Benjamin,
</p>
<p>
note that 4.8.rc1 is already out, should be newer than 4.8.alpha6.
</p>
</blockquote>
<p>
It certainly isn't out yet (and maybe it will never even exist if rc0 solves all our problems). The easiest way to find out the latest development release is <a href="http://www.sagemath.org/download-latest.html">http://www.sagemath.org/download-latest.html</a>, accessible as www.sagemath.org -> Download -> Development Release.
Alternatively, look at the sage-release announcements.
</p>
TicketbenjaminfjonesMon, 09 Jan 2012 21:00:56 GMTstatus changed
https://trac.sagemath.org/ticket/1173#comment:49
https://trac.sagemath.org/ticket/1173#comment:49
<ul>
<li><strong>status</strong>
changed from <em>positive_review</em> to <em>needs_work</em>
</li>
</ul>
<p>
OK, the feeling here at SD35.5 is to hijack this ticket (change the ticket description) to rebase the work done by DSM on top of Sage-4.8.alpha6 (rather than making a new ticket) so the work and documentation improvements here are preserved and compatible with <a class="closed ticket" href="https://trac.sagemath.org/ticket/11948" title="defect: Fix numeric evaluation of error function (closed: fixed)">#11948</a>. Please pipe up if you're following this ticket and have an opinion.
</p>
TicketjdemeyerMon, 09 Jan 2012 21:10:21 GMTmilestone changed
https://trac.sagemath.org/ticket/1173#comment:50
https://trac.sagemath.org/ticket/1173#comment:50
<ul>
<li><strong>milestone</strong>
changed from <em>sage-pending</em> to <em>sage-5.0</em>
</li>
</ul>
<p>
Fine by me.
</p>
TicketbenjaminfjonesTue, 10 Jan 2012 03:43:31 GMTdescription, summary changed
https://trac.sagemath.org/ticket/1173#comment:51
https://trac.sagemath.org/ticket/1173#comment:51
<ul>
<li><strong>description</strong>
modified (<a href="/ticket/1173?action=diff&version=51">diff</a>)
</li>
<li><strong>summary</strong>
changed from <em>implement numerical evaluation of erf at complex arguments</em> to <em>implement numerical evaluation of erf at complex arguments via mpmath algorithm</em>
</li>
</ul>
TicketkcrismanMon, 02 Jul 2012 14:02:22 GMT
https://trac.sagemath.org/ticket/1173#comment:52
https://trac.sagemath.org/ticket/1173#comment:52
<p>
See comments at <a class="closed ticket" href="https://trac.sagemath.org/ticket/11948" title="defect: Fix numeric evaluation of error function (closed: fixed)">#11948</a> for why we probably want to do this or <a class="new ticket" href="https://trac.sagemath.org/ticket/13050" title="enhancement: allow different algorithms for evaluating erf (new)">#13050</a> as soon as possible.
</p>
TicketkcrismanWed, 12 Jun 2013 20:12:30 GMT
https://trac.sagemath.org/ticket/1173#comment:53
https://trac.sagemath.org/ticket/1173#comment:53
<p>
With respect to the move call patch, see also <a class="closed ticket" href="https://trac.sagemath.org/ticket/13933" title="defect: BuiltinFunction.__call__ is unnecessarily slow (closed: fixed)">#13933</a>.
</p>
TicketkcrismanWed, 12 Jun 2013 20:13:49 GMTdescription changed
https://trac.sagemath.org/ticket/1173#comment:54
https://trac.sagemath.org/ticket/1173#comment:54
<ul>
<li><strong>description</strong>
modified (<a href="/ticket/1173?action=diff&version=54">diff</a>)
</li>
</ul>
<p>
Apply trac_1173_complex_erf_v3.patch
</p>
TicketkcrismanWed, 19 Jun 2013 06:20:18 GMTstatus, reviewer, milestone changed; author, dependencies deleted
https://trac.sagemath.org/ticket/1173#comment:55
https://trac.sagemath.org/ticket/1173#comment:55
<ul>
<li><strong>status</strong>
changed from <em>needs_work</em> to <em>positive_review</em>
</li>
<li><strong>reviewer</strong>
changed from <em>Burcin Erocal, Benjamin Jones</em> to <em>Karl-Dieter Crisman</em>
</li>
<li><strong>author</strong>
<em>D. S. McNeil</em> deleted
</li>
<li><strong>dependencies</strong>
<em>#11513</em> deleted
</li>
<li><strong>milestone</strong>
changed from <em>sage-5.11</em> to <em>sage-duplicate/invalid/wontfix</em>
</li>
</ul>
<p>
Pretty much everything here was done at <a class="closed ticket" href="https://trac.sagemath.org/ticket/11948" title="defect: Fix numeric evaluation of error function (closed: fixed)">#11948</a> or <a class="closed ticket" href="https://trac.sagemath.org/ticket/13001" title="enhancement: Rebase documentation improvements in #1173 to sage-5.0 (closed: fixed)">#13001</a>. So let's close this (just a little I moved to <a class="new ticket" href="https://trac.sagemath.org/ticket/13050" title="enhancement: allow different algorithms for evaluating erf (new)">#13050</a>.
</p>
TicketjdemeyerWed, 19 Jun 2013 12:16:37 GMTstatus changed; resolution set
https://trac.sagemath.org/ticket/1173#comment:56
https://trac.sagemath.org/ticket/1173#comment:56
<ul>
<li><strong>status</strong>
changed from <em>positive_review</em> to <em>closed</em>
</li>
<li><strong>resolution</strong>
set to <em>duplicate</em>
</li>
</ul>
Ticket