Sage: Ticket #3426: bessel_K function is broken
https://trac.sagemath.org/ticket/3426
<p>
Currently we have
</p>
<pre class="wiki">sage: bessel_K(10 * I, 10)
---------------------------------------------------------------------------
TypeError Traceback (most recent call last)
/home/bober/sage-3.0.2/devel/sage-bober/sage/functions/<ipython console> in <module>()
/home/bober/sage/local/lib/python2.5/site-packages/sage/functions/special.py in bessel_K(nu, z, algorithm, prec)
586 from sage.libs.pari.all import pari
587 RR,a = _setup(prec)
--> 588 b = RR(pari(nu).besselk(z))
589 pari.set_real_precision(a)
590 return b
/home/bober/sage-3.0.2/devel/sage-bober/sage/functions/real_mpfr.pyx in sage.rings.real_mpfr.RealField.__call__ (sage/rings/real_mpfr.c:3138)()
/home/bober/sage-3.0.2/devel/sage-bober/sage/functions/real_mpfr.pyx in sage.rings.real_mpfr.RealNumber._set (sage/rings/real_mpfr.c:5905)()
TypeError: Unable to convert x (='0.000000098241574381992468+0.E-161*I') to real number.
sage: bessel_K(10 * I, 10)
---------------------------------------------------------------------------
TypeError Traceback (most recent call last)
/home/bober/sage-3.0.2/devel/sage-bober/sage/functions/<ipython console> in <module>()
/home/bober/sage/local/lib/python2.5/site-packages/sage/functions/special.py in bessel_K(nu, z, algorithm, prec)
586 from sage.libs.pari.all import pari
587 RR,a = _setup(prec)
--> 588 b = RR(pari(nu).besselk(z))
589 pari.set_real_precision(a)
590 return b
/home/bober/sage-3.0.2/devel/sage-bober/sage/functions/real_mpfr.pyx in sage.rings.real_mpfr.RealField.__call__ (sage/rings/real_mpfr.c:3138)()
/home/bober/sage-3.0.2/devel/sage-bober/sage/functions/real_mpfr.pyx in sage.rings.real_mpfr.RealNumber._set (sage/rings/real_mpfr.c:5905)()
TypeError: Unable to convert x (='0.000000098241574381992468+0.E-161*I') to real number.
</pre><p>
In this case the result actually should be a real number, so we fix this by discarding the imaginary part of the result from pari. In other cases, however, the result is actually a complex number, and we shouldn't always be attempting to cast it to a real number (which the attached patch also fixes).
</p>
en-usSagehttps://trac.sagemath.org/chrome/site/logo_sagemath_trac.png
https://trac.sagemath.org/ticket/3426
Trac 1.1.6boberSat, 14 Jun 2008 22:10:30 GMTattachment set
https://trac.sagemath.org/ticket/3426
https://trac.sagemath.org/ticket/3426
<ul>
<li><strong>attachment</strong>
set to <em>kbessel_fixes.patch</em>
</li>
</ul>
TicketmabshoffSat, 14 Jun 2008 23:36:54 GMTsummary, milestone changed
https://trac.sagemath.org/ticket/3426#comment:1
https://trac.sagemath.org/ticket/3426#comment:1
<ul>
<li><strong>summary</strong>
changed from <em>bessel_K function is broken (with patch, needs review)</em> to <em>[with patch, needs review] bessel_K function is broken</em>
</li>
<li><strong>milestone</strong>
changed from <em>sage-3.0.3</em> to <em>sage-3.0.4</em>
</li>
</ul>
TicketmalbSun, 15 Jun 2008 01:20:19 GMTowner, component changed
https://trac.sagemath.org/ticket/3426#comment:2
https://trac.sagemath.org/ticket/3426#comment:2
<ul>
<li><strong>owner</strong>
changed from <em>bober</em> to <em>gfurnish</em>
</li>
<li><strong>component</strong>
changed from <em>misc</em> to <em>calculus</em>
</li>
</ul>
TicketcraigcitroSun, 15 Jun 2008 22:05:19 GMTkeywords, summary changed
https://trac.sagemath.org/ticket/3426#comment:3
https://trac.sagemath.org/ticket/3426#comment:3
<ul>
<li><strong>keywords</strong>
<em>editor_gfurnish</em> added
</li>
<li><strong>summary</strong>
changed from <em>[with patch, needs review] bessel_K function is broken</em> to <em>[with patch, under review] bessel_K function is broken</em>
</li>
</ul>
TicketboberMon, 16 Jun 2008 04:18:59 GMT
https://trac.sagemath.org/ticket/3426#comment:4
https://trac.sagemath.org/ticket/3426#comment:4
<p>
Regarding bessel_K being real for real argument and real or imaginary order, see, e.g. the appendix to H. Then, Maass cusp forms for large eigenvalues, Math. Comp. Volume 74, Number 249, pp. 363 - 381: "The K-Bessel function K_ir(x) is ... real for real arguments x and real or imaginary order ir."
</p>
TicketgregorybardMon, 16 Jun 2008 05:18:23 GMT
https://trac.sagemath.org/ticket/3426#comment:5
https://trac.sagemath.org/ticket/3426#comment:5
<p>
I can say that I agree that this is 100% correct.
</p>
TicketgfurnishMon, 16 Jun 2008 05:51:46 GMTsummary changed
https://trac.sagemath.org/ticket/3426#comment:6
https://trac.sagemath.org/ticket/3426#comment:6
<ul>
<li><strong>summary</strong>
changed from <em>[with patch, under review] bessel_K function is broken</em> to <em>[with patch, with positive review] bessel_K function is broken</em>
</li>
</ul>
TicketgfurnishMon, 16 Jun 2008 05:55:58 GMTpriority, milestone changed
https://trac.sagemath.org/ticket/3426#comment:7
https://trac.sagemath.org/ticket/3426#comment:7
<ul>
<li><strong>priority</strong>
changed from <em>minor</em> to <em>major</em>
</li>
<li><strong>milestone</strong>
changed from <em>sage-3.0.4</em> to <em>sage-3.0.3</em>
</li>
</ul>
TicketmabshoffMon, 16 Jun 2008 06:42:01 GMTmilestone changed
https://trac.sagemath.org/ticket/3426#comment:8
https://trac.sagemath.org/ticket/3426#comment:8
<ul>
<li><strong>milestone</strong>
changed from <em>sage-3.0.3</em> to <em>sage-3.0.4</em>
</li>
</ul>
TicketrishiTue, 17 Jun 2008 17:51:12 GMT
https://trac.sagemath.org/ticket/3426#comment:9
https://trac.sagemath.org/ticket/3426#comment:9
<p>
I think a solution of the following type would be better.
</p>
<pre class="wiki">
try:
from sage.libs.pari.all import pari
RR,a = _setup(prec)
b = RR(pari(nu).besselk(z))
pari.set_real_precision
except TypeError:
CC,a = _setup(prec)
b = CC(pari(nu).besselk(z))
pari.set_real_precision(a)
</pre>
TicketrishiTue, 17 Jun 2008 18:14:10 GMT
https://trac.sagemath.org/ticket/3426#comment:10
https://trac.sagemath.org/ticket/3426#comment:10
<p>
Probably the correct code would be
</p>
<pre class="wiki">
try:
from sage.libs.pari.all import pari
RR,a = _setup(prec)
b = RR(pari(nu).besselk(z))
pari.set_real_precision
except TypeError:
CC,a = _setup_CC(prec)
b = CC(pari(nu).besselk(z))
pari.set_real_precision(a)
</pre>
TicketmabshoffMon, 23 Jun 2008 09:36:31 GMTsummary changed
https://trac.sagemath.org/ticket/3426#comment:11
https://trac.sagemath.org/ticket/3426#comment:11
<ul>
<li><strong>summary</strong>
changed from <em>[with patch, with positive review] bessel_K function is broken</em> to <em>[with patch, needs work] bessel_K function is broken</em>
</li>
</ul>
<p>
Since Rishi commented on this it might be a good idea to discuss his comments.
</p>
<p>
Cheers,
</p>
<p>
Michael
</p>
TicketgfurnishMon, 23 Jun 2008 15:22:47 GMTsummary changed
https://trac.sagemath.org/ticket/3426#comment:12
https://trac.sagemath.org/ticket/3426#comment:12
<ul>
<li><strong>summary</strong>
changed from <em>[with patch, needs work] bessel_K function is broken</em> to <em>[with patch, with positive review] bessel_K function is broken</em>
</li>
</ul>
<p>
The try code does not in my opinion work. The issue here is correcting numerical instabilities, which attempting to coerce into RR will not do. Positive review still.
</p>
TicketrishiMon, 23 Jun 2008 18:50:51 GMT
https://trac.sagemath.org/ticket/3426#comment:13
https://trac.sagemath.org/ticket/3426#comment:13
<p>
I am pretty confident that the try code works. Consider the following gp output. The current patch will try to coerce this to RR. If pari is right then this input after applying the patch will give a <a class="missing wiki">TypeError?</a>.
</p>
<pre class="wiki">? besselk(2,-1.121)
%1 = 1.234141459629829380224386595 - 0.5472316582663064541169798027*I
</pre><p>
We probably eliminate the double evaluation of bessel function using pari which my current suggestion does.
</p>
TicketgfurnishMon, 23 Jun 2008 18:54:40 GMT
https://trac.sagemath.org/ticket/3426#comment:14
https://trac.sagemath.org/ticket/3426#comment:14
<p>
I don't understand what double evaluation of the bessel function you are talking about. Furthermore the entire point is that Pari can give wrong answers in some cases because of numerical cases. Therefore we want to manually correct the numerical noise. Trying to coerce into RR instead of clearing it completely misses the point.
</p>
TicketrishiMon, 23 Jun 2008 19:32:40 GMT
https://trac.sagemath.org/ticket/3426#comment:15
https://trac.sagemath.org/ticket/3426#comment:15
<p>
I refuse to believe such a large numerical instabilities. In fact maple gives the same answer as pari. I will investigate further and figure out. You cannot Willy nilly ignore the imaginary part.
</p>
TicketrishiMon, 23 Jun 2008 19:39:56 GMT
https://trac.sagemath.org/ticket/3426#comment:16
https://trac.sagemath.org/ticket/3426#comment:16
<p>
And Mathematica does the same as pari.
</p>
<p>
I suggested the try: except: statement because it does not require deep understanding of Bessel's K function and probably in the end we might end up with this solution.
</p>
TicketgfurnishMon, 23 Jun 2008 20:47:16 GMT
https://trac.sagemath.org/ticket/3426#comment:17
https://trac.sagemath.org/ticket/3426#comment:17
<p>
The try except statement does not significantly help the original complaint. Either the identity is true or we should give the patch a negative review and close it as invalid.
</p>
TicketgfurnishMon, 23 Jun 2008 20:56:05 GMT
https://trac.sagemath.org/ticket/3426#comment:18
https://trac.sagemath.org/ticket/3426#comment:18
<pre class="wiki">besselk(nu,x,{flag = 0})
K-Bessel function of index nu (which can be complex) and argument x. Only real and positive arguments x are allowed in the present version 2.3.3. If flag is equal to 1, uses another implementation of this function which is faster when x >> 1.
The library syntax is kbessel(nu,x,prec) and kbessel2(nu,x,prec) respectively.
</pre><p>
Therefore pari gives incorrect answers for your negative x. Perhaps this is another bug and we should merge this ticket and open another one for adding some error checking to besselk?
</p>
TicketrishiMon, 23 Jun 2008 21:22:02 GMT
https://trac.sagemath.org/ticket/3426#comment:19
https://trac.sagemath.org/ticket/3426#comment:19
<p>
The complaint is valid. In fact the current version is lot more broken that the patched version. The current version does not take any complex argument. The patched version only fails on negative real axis.
</p>
TicketgfurnishMon, 23 Jun 2008 21:58:53 GMT
https://trac.sagemath.org/ticket/3426#comment:20
https://trac.sagemath.org/ticket/3426#comment:20
<p>
Ok lets patch this then and open a new ticket for the negative real axis case.
</p>
TicketrishiMon, 23 Jun 2008 22:07:44 GMT
https://trac.sagemath.org/ticket/3426#comment:21
https://trac.sagemath.org/ticket/3426#comment:21
<p>
I think
</p>
<pre class="wiki">if (real(nu) == 0 or imag(nu) == 0) and (imag(z) == 0)
</pre><p>
should become
</p>
<pre class="wiki">if (real(nu) == 0 or imag(nu) == 0) and (imag(z) == 0 and real(z) > 0)
</pre>
TicketboberTue, 24 Jun 2008 17:24:29 GMTsummary changed
https://trac.sagemath.org/ticket/3426#comment:22
https://trac.sagemath.org/ticket/3426#comment:22
<ul>
<li><strong>summary</strong>
changed from <em>[with patch, with positive review] bessel_K function is broken</em> to <em>[with patch, with mixed review] bessel_K function is broken</em>
</li>
</ul>
<p>
Following the philosophy that wrong answers are worse than errors, this patch should not go in as is. Probably the code in Rishi's most recent comment is all that is needed for a fix, as long as we're not missing something else. I can't fix this at exactly this moment, but the fix should be trivial. Anyway, even though I posted the original patch, I have to give this a -1.
</p>
TicketgfurnishTue, 24 Jun 2008 17:48:37 GMT
https://trac.sagemath.org/ticket/3426#comment:23
https://trac.sagemath.org/ticket/3426#comment:23
<p>
rishi's code does not prevent brokenness at all (in fact it is 100% equivalent to attempting to trying to return RR(answer, prec). The patch as is makes the answer "more correct," and then we can go back and write code (that makes use of this patch) to make it 100% correct. Alternatively, if someone wants to make a new patch that checks for real(z)>=0 in all cases and throws an error otherwise, I would give that a positive review. However, the modification of real(z)>0 is not sufficient to ensure correctness.
</p>
TicketmabshoffMon, 01 Sep 2008 02:41:24 GMTsummary changed
https://trac.sagemath.org/ticket/3426#comment:24
https://trac.sagemath.org/ticket/3426#comment:24
<ul>
<li><strong>summary</strong>
changed from <em>[with patch, with mixed review] bessel_K function is broken</em> to <em>[with patch, needs work] bessel_K function is broken</em>
</li>
</ul>
<p>
This ticket has been sitting around for a while without any movement. Change the title so that the reports pick up this ticket correctly.
</p>
<p>
Cheers,
</p>
<p>
Michael
</p>
TicketAlexGhitzaWed, 17 Sep 2008 10:56:10 GMTcc set
https://trac.sagemath.org/ticket/3426#comment:25
https://trac.sagemath.org/ticket/3426#comment:25
<ul>
<li><strong>cc</strong>
<em>AlexGhitza</em> added
</li>
</ul>
TicketcremonaTue, 23 Sep 2008 11:45:11 GMT
https://trac.sagemath.org/ticket/3426#comment:26
https://trac.sagemath.org/ticket/3426#comment:26
<p>
I note that Alex added himself to the CC for this. Whatever is done for this issue absolutely must take into account the work done for <a class="closed ticket" href="https://trac.sagemath.org/ticket/4096" title="defect: [with patches, positive review] pari precision interface (closed: fixed)">#4096</a>, so at the least I suggest that the author of this patch looks at that one and reworks this. Anything relying on Sage/pari precision questions is likely to be useless otherwise.
</p>
TicketAlexGhitzaWed, 01 Oct 2008 09:46:15 GMTsummary changed; cc deleted
https://trac.sagemath.org/ticket/3426#comment:27
https://trac.sagemath.org/ticket/3426#comment:27
<ul>
<li><strong>cc</strong>
<em>AlexGhitza</em> removed
</li>
<li><strong>summary</strong>
changed from <em>[with patch, needs work] bessel_K function is broken</em> to <em>[with new patch, needs review] bessel_K function is broken</em>
</li>
</ul>
<p>
I looked up the definition and properties of the Bessel functions in
several references (Section 7.2 of the "Bateman Manuscript Project",
for instance).
</p>
<p>
I uploaded a brand new patch that implements the behavior described
there, namely returning a real number if the result is theoretically
known to be real, and a complex number otherwise. I added doctests
that document this behavior, and checked all of them against
Mathematica. I did this for all three Bessel functions that are
implemented in special.py using Pari, namely J, K, and I. I also put in a workaround for a silly Pari buglet that
complains about negative integer values of nu.
</p>
<p>
In the process I uncovered a couple of unrelated issues with
special.py and Bessel functions, for which I'll open separate tickets.
</p>
<p>
The patch is made against 3.1.3.alpha2.
</p>
TicketddrakeFri, 10 Oct 2008 00:40:08 GMT
https://trac.sagemath.org/ticket/3426#comment:28
https://trac.sagemath.org/ticket/3426#comment:28
<p>
Uh oh:
</p>
<pre class="wiki">sage: bessel_J(0,0)
---------------------------------------------------------------------------
PariError Traceback (most recent call last)
/home/drake/.sage/temp/klee/32521/_home_drake__sage_init_sage_0.py in <module>()
----> 1
2
3
4
5
/opt/sage-3.1.3.alpha2/local/lib/python2.5/site-packages/sage/functions/special.pyc in bessel_J(nu, z, algorithm, prec)
570 z = C(z)
571 K = C
--> 572 pari_bes = pari(nu).besselj(z, precision=prec)
573 if K is R:
574 return fudge*K(pari_bes.real())
/opt/sage-3.1.3.alpha2/local/lib/python2.5/site-packages/sage/libs/pari/gen.so in sage.libs.pari.gen._pari_trap (sage/libs/pari/gen.c:34414)()
7865
7866
-> 7867
7868
7869
PariError: (8)
</pre><p>
Doing <code>bessel_J(0, 0)</code> in 3.1.2 works fine. I get similar errors with this patch for other Bessel functions, too.
</p>
TicketAlexGhitzaFri, 10 Oct 2008 01:21:44 GMT
https://trac.sagemath.org/ticket/3426#comment:29
https://trac.sagemath.org/ticket/3426#comment:29
<p>
Thanks for catching this. It actually comes from a bug in Pari:
</p>
<pre class="wiki">? besselj(0, 0)
%1 = 1.000000000000000000000000000
? besselj(0.E-19, 0)
*** besselj: gpow: 0 to a non positive exponent.
</pre><p>
I've reported it upstream, but I will post a patch with a workaround while we wait.
</p>
TicketAlexGhitzaFri, 10 Oct 2008 12:27:47 GMTattachment set
https://trac.sagemath.org/ticket/3426
https://trac.sagemath.org/ticket/3426
<ul>
<li><strong>attachment</strong>
set to <em>trac3426-fix-bessel-fns.patch</em>
</li>
</ul>
<p>
apply instead of the previous patch
</p>
TicketAlexGhitzaFri, 10 Oct 2008 12:28:54 GMT
https://trac.sagemath.org/ticket/3426#comment:30
https://trac.sagemath.org/ticket/3426#comment:30
<p>
OK, I've replaced my patch with one that fixes the issue reported by Dan.
</p>
TicketddrakeMon, 20 Oct 2008 05:57:21 GMT
https://trac.sagemath.org/ticket/3426#comment:31
https://trac.sagemath.org/ticket/3426#comment:31
<p>
Now <code>bessel_J(0,0)</code> works but I'm seeing other problems. I'm concentrating here on the "K" functions since that's what this ticket is about. This is all with the current patch applied to 3.1.4.
</p>
<ul><li><code>bessel_K(0, -1)</code> doesn't work at all; it just soaks up all the CPU and doesn't return. The correct answer is about <code>0.421024438240708 - 3.97746326050642*I</code>.
</li></ul><ul><li><code>bessel_K(-1*I - 1, 0)</code> gives an uninformative Pari error; the function isn't defined there. Mathematica says "<a class="missing wiki">ComplexInfinity?</a>"; can we give a better error message? Even just "function not defined at 0" would be fine.
</li></ul><ul><li><code>bessel_K(-1, -1)</code> says it can't convert <code>-0.601907230197235-1.77549968921218*I</code> to a real number, which I agree with. :) It looks like Pari has the right answer but we're trying to convert it to a real when we shouldn't be.
</li></ul><ul><li><code>bessel_K(0, -1 - I)</code> says "incorrect type", but Mathematica and Maple evaluate it just fine.
</li></ul>
TicketAlexGhitzaSat, 22 Nov 2008 07:44:03 GMTsummary changed
https://trac.sagemath.org/ticket/3426#comment:32
https://trac.sagemath.org/ticket/3426#comment:32
<ul>
<li><strong>summary</strong>
changed from <em>[with new patch, needs review] bessel_K function is broken</em> to <em>[with patch, needs work] bessel_K function is broken</em>
</li>
</ul>
TicketrlmThu, 22 Jan 2009 18:53:11 GMT
https://trac.sagemath.org/ticket/3426#comment:33
https://trac.sagemath.org/ticket/3426#comment:33
<p>
See <a class="closed ticket" href="https://trac.sagemath.org/ticket/4626" title="defect: [with patch, positive review] error in bessel_J(0,0) (closed: fixed)">#4626</a>, which at least fixes the <code>bessel_J</code> problem.
</p>
TicketAlexGhitzaWed, 20 Jan 2010 07:13:58 GMTkeywords, summary changed; upstream set
https://trac.sagemath.org/ticket/3426#comment:34
https://trac.sagemath.org/ticket/3426#comment:34
<ul>
<li><strong>keywords</strong>
<em>editor_gfurnish</em> removed
</li>
<li><strong>upstream</strong>
set to <em>N/A</em>
</li>
<li><strong>summary</strong>
changed from <em>[with patch, needs work] bessel_K function is broken</em> to <em>bessel_K function is broken</em>
</li>
</ul>
<p>
This ticket is a huge mess :)
</p>
<p>
I now think that we should just use mpmath to evaluate Bessel functions, see
</p>
<p>
<a class="ext-link" href="http://mpmath.googlecode.com/svn/trunk/doc/build/functions/bessel.html"><span class="icon"></span>http://mpmath.googlecode.com/svn/trunk/doc/build/functions/bessel.html</a>
</p>
<p>
For the examples that Dan gave:
</p>
<pre class="wiki">sage: from mpmath import *
sage: mp.dps = 25; mp.pretty = True
sage: besselk(0, -1)
(0.4210244382407083333356274 - 3.97746326050642263725661j)
sage: besselk(-1*I - 1, 0)
+inf
sage: besselk(-1, -1)
(-0.60190723019723457473754 - 1.775499689212180946878577j)
sage: besselk(0, -1-I)
(-1.479697108749625193260947 + 2.588306443392007370808151j)
</pre>
TicketrishiWed, 20 Jan 2010 21:04:20 GMT
https://trac.sagemath.org/ticket/3426#comment:35
https://trac.sagemath.org/ticket/3426#comment:35
<p>
From my quick experiments with the issues Bober was dealing with a year ago, I see that do not arise if we use mpmath, even when I set the precision to 5000.
</p>
<p>
I agree with Alex Ghitza.
</p>
<p>
I should say that the bessels functions for non integer indices have always bothered me. I believe computing will involve a log, and how do you consistently choose a branch.
</p>
TicketddrakeThu, 21 Jan 2010 00:41:37 GMT
https://trac.sagemath.org/ticket/3426#comment:36
https://trac.sagemath.org/ticket/3426#comment:36
<p>
I also agree with Alex -- both in that this ticket is a mess, and that we should just use mpmath. I'll see if I can work up a patch (although anyone else who wants to should feel free to do it).
</p>
TicketrishiFri, 22 Jan 2010 18:32:59 GMT
https://trac.sagemath.org/ticket/3426#comment:37
https://trac.sagemath.org/ticket/3426#comment:37
<p>
With some experiments, I saw that the branch of the log taken is the negative real axis. We should mention this in the documentation when it is implemented. I believe ddrake is working up a patch.
</p>
TicketburcinSun, 24 Jan 2010 17:14:49 GMTcc set
https://trac.sagemath.org/ticket/3426#comment:38
https://trac.sagemath.org/ticket/3426#comment:38
<ul>
<li><strong>cc</strong>
<em>burcin</em> added
</li>
</ul>
TicketddrakeThu, 18 Feb 2010 09:28:59 GMT
https://trac.sagemath.org/ticket/3426#comment:39
https://trac.sagemath.org/ticket/3426#comment:39
<p>
Here are some more problems with bessel_K: <a class="ext-link" href="http://groups.google.com/group/sage-support/browse_thread/thread/84e5cd4fb1381ad5"><span class="icon"></span>http://groups.google.com/group/sage-support/browse_thread/thread/84e5cd4fb1381ad5</a>
</p>
<p>
In resolving this ticket, we should make sure to have doctests related to those problems!
</p>
TicketkcrismanWed, 16 Mar 2011 15:37:36 GMTcc changed
https://trac.sagemath.org/ticket/3426#comment:40
https://trac.sagemath.org/ticket/3426#comment:40
<ul>
<li><strong>cc</strong>
<em>kcrisman</em> added
</li>
</ul>
TicketkcrismanThu, 03 Jan 2013 15:32:46 GMTcc changed
https://trac.sagemath.org/ticket/3426#comment:41
https://trac.sagemath.org/ticket/3426#comment:41
<ul>
<li><strong>cc</strong>
<em>benjaminfjones</em> added
</li>
</ul>
<p>
This would most likely be fixed by <a class="closed ticket" href="https://trac.sagemath.org/ticket/4102" title="enhancement: make bessel_J symbolic (closed: fixed)">#4102</a>.
</p>
TicketbenjaminfjonesThu, 03 Jan 2013 23:07:45 GMT
https://trac.sagemath.org/ticket/3426#comment:42
https://trac.sagemath.org/ticket/3426#comment:42
<p>
Yes, it will be fixed by <a class="closed ticket" href="https://trac.sagemath.org/ticket/4102" title="enhancement: make bessel_J symbolic (closed: fixed)">#4102</a>. I'll make a note to add a related doctest to that effect.
</p>
TicketkcrismanFri, 08 Feb 2013 17:34:18 GMTstatus, milestone changed; reviewer set
https://trac.sagemath.org/ticket/3426#comment:43
https://trac.sagemath.org/ticket/3426#comment:43
<ul>
<li><strong>status</strong>
changed from <em>needs_work</em> to <em>positive_review</em>
</li>
<li><strong>reviewer</strong>
set to <em>Karl-Dieter Crisman, Benjamin Jones</em>
</li>
<li><strong>milestone</strong>
changed from <em>sage-5.7</em> to <em>sage-duplicate/invalid/wontfix</em>
</li>
</ul>
<p>
Everything here is now in a doctest in <a class="closed ticket" href="https://trac.sagemath.org/ticket/4102" title="enhancement: make bessel_J symbolic (closed: fixed)">#4102</a>, including the stuff in the thread from three (!) years ago.
</p>
TicketjdemeyerSun, 17 Feb 2013 20:10:42 GMTstatus changed; resolution set
https://trac.sagemath.org/ticket/3426#comment:44
https://trac.sagemath.org/ticket/3426#comment:44
<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