Sage: Ticket #4102: make bessel_J symbolic
https://trac.sagemath.org/ticket/4102
<p>
The motivation for this is
</p>
<pre class="wiki">sage: plot(bessel_J(1, x), (x, 1, 10))
Traceback (most recent call last):
...
TypeError: Unable to convert x (='1-1/8*x^2+1/192*x^4-1/9216*x^6+1/737280*x^8-1/88473600*x^10+1/14863564800*x^12-1/3329438515200*x^14+1/958878292377600*x^16+O(x^17)') to real number.
</pre><p>
The problem is that special functions, or at least <code>bessel_J</code>, can't currently be partially evaluated--that is, called with a <code>SymbolicExpression</code> as an argument. The model of good behavior is <code>polylog</code>, for which the above method produces a perfectly nice plot
</p>
<pre class="wiki">sage: plot(polylog(1,x),(x,.1,.9)) #makes a fine plot
</pre><p>
See discussion at <a class="ext-link" href="http://groups.google.com/group/sage-support/browse_thread/thread/1b985b080ba2369e/7dee9eed953857f5#7dee9eed953857f5"><span class="icon"></span>http://groups.google.com/group/sage-support/browse_thread/thread/1b985b080ba2369e/7dee9eed953857f5#7dee9eed953857f5</a>
</p>
<hr />
<p>
Release manager:
</p>
<p>
Apply:
</p>
<ul><li><a class="attachment" href="https://trac.sagemath.org/attachment/ticket/4102/trac_symbolic_bessel_v7.2.patch" title="Attachment 'trac_symbolic_bessel_v7.2.patch' in Ticket #4102">attachment:trac_symbolic_bessel_v7.2.patch</a><a class="trac-rawlink" href="https://trac.sagemath.org/raw-attachment/ticket/4102/trac_symbolic_bessel_v7.2.patch" title="Download"></a>,
</li><li><a class="attachment" href="https://trac.sagemath.org/attachment/ticket/4102/trac_symbolic_bessel_v7-doctests.patch" title="Attachment 'trac_symbolic_bessel_v7-doctests.patch' in Ticket #4102">attachment:trac_symbolic_bessel_v7-doctests.patch</a><a class="trac-rawlink" href="https://trac.sagemath.org/raw-attachment/ticket/4102/trac_symbolic_bessel_v7-doctests.patch" title="Download"></a>,
</li><li><a class="attachment" href="https://trac.sagemath.org/attachment/ticket/4102/bessel_2.2.patch" title="Attachment 'bessel_2.2.patch' in Ticket #4102">attachment:bessel_2.2.patch</a><a class="trac-rawlink" href="https://trac.sagemath.org/raw-attachment/ticket/4102/bessel_2.2.patch" title="Download"></a>
</li><li><a class="attachment" href="https://trac.sagemath.org/attachment/ticket/4102/trac_4102-bessel_doctest_fixes2.patch" title="Attachment 'trac_4102-bessel_doctest_fixes2.patch' in Ticket #4102">attachment:trac_4102-bessel_doctest_fixes2.patch</a><a class="trac-rawlink" href="https://trac.sagemath.org/raw-attachment/ticket/4102/trac_4102-bessel_doctest_fixes2.patch" title="Download"></a>
</li></ul>en-usSagehttps://trac.sagemath.org/chrome/site/logo_sagemath_trac.png
https://trac.sagemath.org/ticket/4102
Trac 1.1.6ddrakeFri, 12 Sep 2008 02:14:56 GMT
https://trac.sagemath.org/ticket/4102#comment:1
https://trac.sagemath.org/ticket/4102#comment:1
<p>
Orthogonal polynomials seem to work fine; you can plot the <code>legendre_P</code>, <code>hermite</code>, and <code>jacobi_P</code> polynomials with <code>plot(legendre_P(4, x), (x,-1,1))</code> and so on. So whatever magic they are using might work for the Bessel functions and other special functions.
</p>
TicketjasonFri, 12 Sep 2008 04:00:02 GMTkeywords set
https://trac.sagemath.org/ticket/4102#comment:2
https://trac.sagemath.org/ticket/4102#comment:2
<ul>
<li><strong>keywords</strong>
<em>jason</em> added
</li>
</ul>
TicketjasonFri, 12 Sep 2008 04:00:09 GMTcc set; keywords deleted
https://trac.sagemath.org/ticket/4102#comment:3
https://trac.sagemath.org/ticket/4102#comment:3
<ul>
<li><strong>cc</strong>
<em>jason</em> added
</li>
<li><strong>keywords</strong>
<em>jason</em> removed
</li>
</ul>
TicketkcrismanMon, 17 Jan 2011 17:49:22 GMTcc changed; upstream set
https://trac.sagemath.org/ticket/4102#comment:4
https://trac.sagemath.org/ticket/4102#comment:4
<ul>
<li><strong>cc</strong>
<em>kcrisman</em> added
</li>
<li><strong>upstream</strong>
set to <em>N/A</em>
</li>
</ul>
TicketburcinTue, 14 Jun 2011 18:22:41 GMTsummary changed
https://trac.sagemath.org/ticket/4102#comment:5
https://trac.sagemath.org/ticket/4102#comment:5
<ul>
<li><strong>summary</strong>
changed from <em>Make special functions behave like PrimitiveFunction</em> to <em>make bessel_J symbolic</em>
</li>
</ul>
<p>
This ticket description was too broad. We have lots of tickets on fixing symbolic functions, see <a class="wiki" href="https://trac.sagemath.org/wiki/symbolics/functions">symbolics/functions</a> for an overview.
</p>
<p>
See <a class="closed ticket" href="https://trac.sagemath.org/ticket/3426" title="defect: bessel_K function is broken (closed: duplicate)">#3426</a> and <a class="closed ticket" href="https://trac.sagemath.org/ticket/4230" title="enhancement: implement arbitrary precision Bessel Y function (closed: duplicate)">#4230</a> for other tickets related to bessel functions. It would make sense to fix all these together, with a base class that handles the common properties of bessel functions (differentiation), and subclasses that implement numerical evaluation, etc. for each type.
</p>
TicketbenjaminfjonesWed, 11 Apr 2012 02:45:15 GMTcc, description changed
https://trac.sagemath.org/ticket/4102#comment:6
https://trac.sagemath.org/ticket/4102#comment:6
<ul>
<li><strong>cc</strong>
<em>benjaminfjones</em> added
</li>
<li><strong>description</strong>
modified (<a href="/ticket/4102?action=diff&version=6">diff</a>)
</li>
</ul>
TicketkcrismanSun, 16 Sep 2012 03:05:40 GMT
https://trac.sagemath.org/ticket/4102#comment:7
https://trac.sagemath.org/ticket/4102#comment:7
<p>
See also <a class="new ticket" href="https://trac.sagemath.org/ticket/10636" title="enhancement: Make Bessel zeros available symbolically (new)">#10636</a>, which I somehow never saw before. <a class="ext-link" href="https://groups.google.com/forum/?fromgroups=#!topic/sage-support/XzpN97E26qQ"><span class="icon"></span>This sage-support thread</a> yields an interesting related error:
</p>
<pre class="wiki">sage: var('k')
k
sage: Z = sum( ((-1)^k*(x^(2*k+1))/factorial(2*k+1)),k,0,oo)
sage: Z
1/2*sqrt(pi)*sqrt(2)*sqrt(x)*bessel_j(1/2, x)
sage: Z(x=3)
1/2*sqrt(pi)*sqrt(2)*sqrt(3)*bessel_j(1/2, 3)
sage: Z(x=3).n()
---------------------------------------------------------------------------
TypeError Traceback (most recent call last)
sage.symbolic.expression.Expression._numerical_approx (sage/symbolic/expression.cpp:20822)()
TypeError: cannot evaluate symbolic expression numerically
sage: besse
bessel_I bessel_J bessel_K bessel_Y
</pre><p>
Note that we apparently aren't yet converting Maxima's Bessel properly to 'our' uppercase version because of this.
</p>
TicketbenjaminfjonesWed, 03 Oct 2012 03:03:29 GMT
https://trac.sagemath.org/ticket/4102#comment:8
https://trac.sagemath.org/ticket/4102#comment:8
<p>
This wouldn't be hard to implement using <a class="closed ticket" href="https://trac.sagemath.org/ticket/11143" title="defect: define symbolic functions for exponential integrals (closed: fixed)">#11143</a> as a template, but what to do about names? I guess new names for the symbolic Bessel functions should be chosen and deprecation notices added to the existing <code>Bessel_J</code> etc.
</p>
<p>
What new names do people like in the interim?
</p>
<ul><li><code>bessel_J_symbolic</code>
</li><li><code>bessel_J_sym</code>
</li><li><code>bessel_Js</code>
</li></ul><p>
???
</p>
TicketburcinWed, 03 Oct 2012 11:22:29 GMT
https://trac.sagemath.org/ticket/4102#comment:9
https://trac.sagemath.org/ticket/4102#comment:9
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/4102#comment:8" title="Comment 8">benjaminfjones</a>:
</p>
<blockquote class="citation">
<p>
What new names do people like in the interim?
</p>
<ul><li><code>bessel_J_symbolic</code>
</li><li><code>bessel_J_sym</code>
</li><li><code>bessel_Js</code>
</li></ul><p>
???
</p>
</blockquote>
<p>
What is wrong with taking over <code>bessel_{I,J,K,Y}</code>? Why do we need interim names?
</p>
<p>
Thanks for looking into this.
</p>
TicketkcrismanWed, 03 Oct 2012 14:00:33 GMT
https://trac.sagemath.org/ticket/4102#comment:10
https://trac.sagemath.org/ticket/4102#comment:10
<blockquote class="citation">
<p>
What is wrong with taking over <code>bessel_{I,J,K,Y}</code>? Why do we need interim names?
</p>
</blockquote>
<p>
I concur.
</p>
<blockquote class="citation">
<blockquote class="citation">
<ul><li><code>bessel_J_symbolic</code>
</li></ul></blockquote>
</blockquote>
<p>
One could use that as the "symbolic" class one and then do the usual <code>foo = Foo_Class()</code>?
</p>
<blockquote class="citation">
<p>
Thanks for looking into this.
</p>
</blockquote>
<p>
Agreed!
</p>
TicketddrakeWed, 03 Oct 2012 16:29:27 GMT
https://trac.sagemath.org/ticket/4102#comment:11
https://trac.sagemath.org/ticket/4102#comment:11
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/4102#comment:8" title="Comment 8">benjaminfjones</a>:
</p>
<blockquote class="citation">
<p>
What new names do people like in the interim?
</p>
</blockquote>
<p>
I agree with Burcin: just use <code>bessel_J</code> (etc) if possible.
</p>
<p>
But regardless of the name, I'd love to see this get in -- it will make teaching a PDE class a bit easier. (No more <code>lambda</code> expressions in the plots...) Thanks for working on this!
</p>
TicketbenjaminfjonesMon, 19 Nov 2012 07:10:06 GMTcc changed; author set
https://trac.sagemath.org/ticket/4102#comment:12
https://trac.sagemath.org/ticket/4102#comment:12
<ul>
<li><strong>cc</strong>
<em>dsm</em> added
</li>
<li><strong>author</strong>
set to <em>Benjamin Jones</em>
</li>
</ul>
<p>
I thought I'd post some work in progress for all the Bessel function fans in the crowd. There is still work to be done, e.g.
</p>
<ul><li>getting symbolic integration via Maxima to work
</li><li>adding maxima, scipy, PARI, etc. to the implemented backend systems
</li><li>more documentation and doctests
</li></ul><p>
but at this point the patch applies cleanly to 5.4.1 and all the doctests in <code>sage/functions/special.py</code> pass.
</p>
<p>
If you are interested, have a look at the doctests included with the <code>Bessel</code> function for examples and let me know if you see any serious problems (other than the deficits I've listed above).
</p>
<p>
Thanks!
</p>
TicketbenjaminfjonesMon, 19 Nov 2012 07:11:09 GMTattachment set
https://trac.sagemath.org/ticket/4102
https://trac.sagemath.org/ticket/4102
<ul>
<li><strong>attachment</strong>
set to <em>trac_symbolic_bessel.metaclass.2.patch</em>
</li>
</ul>
<p>
work in progress making Bessel functions symbolic
</p>
TicketkcrismanTue, 20 Nov 2012 01:01:12 GMT
https://trac.sagemath.org/ticket/4102#comment:13
https://trac.sagemath.org/ticket/4102#comment:13
<p>
Nice! A few comments of the type you solicited:
</p>
<ul><li>Why <code>typ</code> and not <code>type</code>? Some Python reserved thing, maybe? But it looks like a typ-o to the (quickly reading) end user.
</li><li>I'd like to be able to plot <code>f(x) = Bessel(0)</code> but maybe that doesn't make sense? I guess a variable is necessary... anyway, just throwing it out there.
</li><li><code>f = maxima(Bessel(typ='K')(x,y))</code> turns out great, but does it convert back? Like <code>f.derivative('y')</code> is <code>-(bessel_k(x+1,y)+bessel_k(x-1,y))/2</code>, but does it then (when put in the <code>_sage_</code> method) go back to "our" uppercase Bessel functions?
</li><li>Maybe Python 3 string formatting? Though I am not sure how to mix that with LaTeX braces.
</li><li>At least some of the error messages should be in doctests, maybe the ones with the wrong type and a non-implemented system.
</li><li><code>class_attrs['_conversions'] = {} </code> --- what do we do with this in Maxima, then? Maybe it's better to raise an error; Maxima tends to otherwise just take things as new variables, which could be dangerous.
</li><li>How many of the currently-deleted doctests do you think would be worth preserving in the long run? Any deprecation needed here?
</li></ul><p>
Anyway, clearly a lot of planning and looks very promising!
</p>
TicketburcinTue, 20 Nov 2012 11:13:08 GMT
https://trac.sagemath.org/ticket/4102#comment:14
https://trac.sagemath.org/ticket/4102#comment:14
<p>
Thanks for the patch. Bessel functions are symbolic with so few lines of code. Amazing. :)
</p>
<p>
I like the metaclass idea. That never occured to me before as an option for functions with parameters, like the order here. I have a few questions:
</p>
<ul><li>what is the advantage of creating a new symbolic function for each (type, order) pair, instead of having a generic function for each type that takes the order as a parameter? The latter would be similar to the design of the <code>psi()</code> function in GiNaC/Pynac.
</li></ul><ul><li>wouldn't this approach make life harder if in the future we want to add exact evaluation method for Bessel_J only?
</li></ul><p>
I am also concerned about blowing up the symbolic function registry with these instances. Note that we keep an entry in a C++ list with a pointer to all the possible custom methods, and a Python dictionary with a function -> Pynac id mapping for each subclass of <code>BuiltinFunction</code> that is instantiated.
</p>
<p>
BTW, I suggest moving this code to a new file <code>sage/functions/bessel.py</code>.
</p>
TicketbenjaminfjonesThu, 27 Dec 2012 20:18:41 GMT
https://trac.sagemath.org/ticket/4102#comment:15
https://trac.sagemath.org/ticket/4102#comment:15
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/4102#comment:13" title="Comment 13">kcrisman</a>:
</p>
<p>
Thanks for the comments. I finally found some time to get back to this ticket :)
</p>
<blockquote class="citation">
<p>
Nice! A few comments of the type you solicited:
</p>
<ul><li>Why <code>typ</code> and not <code>type</code>? Some Python reserved thing, maybe? But it looks like a typ-o to the (quickly reading) end user.
</li></ul></blockquote>
<p>
That was intentional, I was trying not to shadow the builtin name.
</p>
<blockquote class="citation">
<ul><li>I'd like to be able to plot <code>f(x) = Bessel(0)</code> but maybe that doesn't make sense? I guess a variable is necessary... anyway, just throwing it out there.
</li></ul></blockquote>
<p>
I think <code>f(x) = Bessel(0,x)</code> is better, I don't like <code>x</code> being implicit on the right hand side.
</p>
<blockquote class="citation">
<ul><li><code>f = maxima(Bessel(typ='K')(x,y))</code> turns out great, but does it convert back? Like <code>f.derivative('y')</code> is <code>-(bessel_k(x+1,y)+bessel_k(x-1,y))/2</code>, but does it then (when put in the <code>_sage_</code> method) go back to "our" uppercase Bessel functions?
</li></ul></blockquote>
<p>
Good question, I haven't tested it out. I think I'm going to rewrite most of the code anyway so I'll keep this in mind.
</p>
<blockquote class="citation">
<ul><li>Maybe Python 3 string formatting? Though I am not sure how to mix that with LaTeX braces.
</li></ul></blockquote>
<p>
???
</p>
<blockquote class="citation">
<ul><li>At least some of the error messages should be in doctests, maybe the ones with the wrong type and a non-implemented system.
</li></ul></blockquote>
<p>
Good point, I'll make sure to doctest the exceptions.
</p>
<blockquote class="citation">
<ul><li><code>class_attrs['_conversions'] = {} </code> --- what do we do with this in Maxima, then? Maybe it's better to raise an error; Maxima tends to otherwise just take things as new variables, which could be dangerous.
</li></ul></blockquote>
<p>
I don't know about this. I had this in the case of the single parameter functions like <code>Bessel(1,'K')</code> that Maxima doesn't have equivalents for (it just has the two parameter functions). I think I'll scrap the idea of having all infinitely many one-parameter Bessel functions registered as their own symbolic functions (see Burcin's comments below).
</p>
<blockquote class="citation">
<ul><li>How many of the currently-deleted doctests do you think would be worth preserving in the long run? Any deprecation needed here?
</li></ul></blockquote>
<p>
Ideally all of them. Some will need to be modified because of the change in numerical back-end.
</p>
<blockquote class="citation">
<p>
Anyway, clearly a lot of planning and looks very promising!
</p>
</blockquote>
TicketbenjaminfjonesThu, 27 Dec 2012 20:27:10 GMT
https://trac.sagemath.org/ticket/4102#comment:16
https://trac.sagemath.org/ticket/4102#comment:16
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/4102#comment:14" title="Comment 14">burcin</a>:
</p>
<p>
Thanks for looking at it!
</p>
<blockquote class="citation">
<p>
Thanks for the patch. Bessel functions are symbolic with so few lines of code. Amazing. :)
</p>
<p>
I like the metaclass idea. That never occured to me before as an option for functions with parameters, like the order here. I have a few questions:
</p>
<ul><li>what is the advantage of creating a new symbolic function for each (type, order) pair, instead of having a generic function for each type that takes the order as a parameter? The latter would be similar to the design of the <code>psi()</code> function in GiNaC/Pynac.
</li></ul></blockquote>
<p>
The advantage I had in mind was just code reuse. In hindsight though, this approach makes the code more complicated and less maintainable that it needs to be. I'm going to refactor it into four generic functions in <code>sage/functions/bessel.py</code> as you suggest.
</p>
<blockquote class="citation">
<ul><li>wouldn't this approach make life harder if in the future we want to add exact evaluation method for Bessel_J only?
</li></ul></blockquote>
<p>
Good point..
</p>
<blockquote class="citation">
<p>
I am also concerned about blowing up the symbolic function registry with these instances. Note that we keep an entry in a C++ list with a pointer to all the possible custom methods, and a Python dictionary with a function -> Pynac id mapping for each subclass of <code>BuiltinFunction</code> that is instantiated.
</p>
</blockquote>
<p>
Also a good point. This occurred to me, but I didn't think through the consequences very much. I can see it being a problem if a user can inadvertently create a very large number of symbolic functions at runtime by doing something innocuous like:
</p>
<pre class="wiki">sage: point([ (k, Bessel(k, 'J')(pi)) for k in range(1000) ])
... (1000 new symbolic function classes created!)
</pre><blockquote class="citation">
<p>
BTW, I suggest moving this code to a new file <code>sage/functions/bessel.py</code>.
</p>
</blockquote>
<p>
Good idea. New patch coming soon...
</p>
TicketkcrismanThu, 27 Dec 2012 20:44:38 GMT
https://trac.sagemath.org/ticket/4102#comment:17
https://trac.sagemath.org/ticket/4102#comment:17
<blockquote class="citation">
<blockquote class="citation">
<ul><li>Maybe Python 3 string formatting? Though I am not sure how to mix that with LaTeX braces.
</li></ul></blockquote>
<p>
???
</p>
</blockquote>
<p>
Such as <a class="ext-link" href="http://docs.python.org/3.1/library/stdtypes.html#str.format"><span class="icon"></span>this</a> and <a class="ext-link" href="http://docs.python.org/3.1/library/string.html#formatstrings"><span class="icon"></span>this</a>. Just for forward-compatibility (instead of the percent business). Problem is that when I looked for ways to get around braces "naturally" occurring in LaTeX, there weren't necessarily a lot of them. (Ways, that is.)
</p>
TicketbenjaminfjonesThu, 27 Dec 2012 23:53:51 GMT
https://trac.sagemath.org/ticket/4102#comment:18
https://trac.sagemath.org/ticket/4102#comment:18
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/4102#comment:17" title="Comment 17">kcrisman</a>:
</p>
<blockquote class="citation">
<blockquote class="citation">
<blockquote class="citation">
<ul><li>Maybe Python 3 string formatting? Though I am not sure how to mix that with LaTeX braces.
</li></ul></blockquote>
<p>
???
</p>
</blockquote>
<p>
Such as <a class="ext-link" href="http://docs.python.org/3.1/library/stdtypes.html#str.format"><span class="icon"></span>this</a> and <a class="ext-link" href="http://docs.python.org/3.1/library/string.html#formatstrings"><span class="icon"></span>this</a>. Just for forward-compatibility (instead of the percent business). Problem is that when I looked for ways to get around braces "naturally" occurring in LaTeX, there weren't necessarily a lot of them. (Ways, that is.)
</p>
</blockquote>
<p>
Oh, right. I just didn't see what in the code you were referring to. I see now.
</p>
<p>
Anyway, to one of your earlier questions, with the new code I'm about to post the following conversions to and from Maxima work great:
</p>
<pre class="wiki">sage: mb = maxima(bessel_I(1,x))
sage: mb.sage()
bessel_I(1, x)
sage: x,y = var('x,y')
sage: f = maxima(Bessel(typ='K')(x,y))
sage: f.derivative('x')
%pi*csc(%pi*x)*('diff(bessel_i(-x,y),x,1)-'diff(bessel_i(x,y),x,1))/2-%pi*bessel_k(x,y)*cot(%pi*x)
sage: m = f.derivative('x')
sage: m.sage()
-1/2*(x*bessel_I(-x, y)/y - x*bessel_I(x, y)/y + bessel_I(-x - 1, y) + bessel_I(x - 1, y))*pi*csc(pi*x) - pi*cot(pi*x)*bessel_K(x, y)
</pre>
TicketbenjaminfjonesFri, 28 Dec 2012 01:48:57 GMTattachment set
https://trac.sagemath.org/ticket/4102
https://trac.sagemath.org/ticket/4102
<ul>
<li><strong>attachment</strong>
set to <em>trac_symbolic_bessel_v2.patch</em>
</li>
</ul>
<p>
more work in progress
</p>
TicketkcrismanThu, 03 Jan 2013 15:25:29 GMT
https://trac.sagemath.org/ticket/4102#comment:19
https://trac.sagemath.org/ticket/4102#comment:19
<p>
Just as an FYI, <a class="ext-link" href="http://ask.sagemath.org/question/2129/arbitrary-precision-bessely"><span class="icon"></span>this ask.sagemath question</a> wants lots and lots of precision on Bessel Y. Which I think will be provided here via mpmath - just pointing out we should doctest it.
</p>
TicketkcrismanThu, 03 Jan 2013 15:38:06 GMT
https://trac.sagemath.org/ticket/4102#comment:20
https://trac.sagemath.org/ticket/4102#comment:20
<p>
Also, I think that <a class="closed ticket" href="https://trac.sagemath.org/ticket/3426" title="defect: bessel_K function is broken (closed: duplicate)">#3426</a> and <a class="closed ticket" href="https://trac.sagemath.org/ticket/4230" title="enhancement: implement arbitrary precision Bessel Y function (closed: duplicate)">#4230</a> probably would be solved by a successful resolution of this ticket. Let's make sure to include any suggested (and useful) doctests from there here.
</p>
TicketbenjaminfjonesSun, 13 Jan 2013 05:05:37 GMT
https://trac.sagemath.org/ticket/4102#comment:21
https://trac.sagemath.org/ticket/4102#comment:21
<p>
Yet more work in progress, added lots of doctests, in particular to show that problems in <a class="closed ticket" href="https://trac.sagemath.org/ticket/4230" title="enhancement: implement arbitrary precision Bessel Y function (closed: duplicate)">#4230</a> and <a class="closed ticket" href="https://trac.sagemath.org/ticket/3426" title="defect: bessel_K function is broken (closed: duplicate)">#3426</a> are fixed by this patch. One feature this patch adds is the ability to solve
Bessel's diffeq (using Maxima) and get a usable symbolic solution back (see the doctests in the module level docstring and in the Bessel() function).
</p>
<p>
Added brief mathematical exposition on the module docstring as well as some usage EXAMPLES.
</p>
<p>
I think the patch is more or less ready for initial review. All tests withing the new file <code>sage/functions/bessel.py</code> pass on my machine and sage-5.6.beta3, but there are several doctests failing in other places that reference the Bessel functions. I'll work on patching those up for the next iteration.
</p>
TicketbenjaminfjonesSun, 13 Jan 2013 05:06:15 GMTattachment set
https://trac.sagemath.org/ticket/4102
https://trac.sagemath.org/ticket/4102
<ul>
<li><strong>attachment</strong>
set to <em>trac_symbolic_bessel_v3.patch</em>
</li>
</ul>
<p>
more work in progress, v3
</p>
TicketkcrismanFri, 08 Feb 2013 17:36:59 GMT
https://trac.sagemath.org/ticket/4102#comment:22
https://trac.sagemath.org/ticket/4102#comment:22
<p>
Dumb comments since I don't have time for proper review - and more importantly, there are no obvious horrible things (though I haven't gone in depth with branches yet). If all this really works and there are no typos, I think this will be a VERY nice addition.
</p>
<ul><li><code>unqiue</code> typo
</li><li><code>Verfify</code> typo
</li><li><code>increasin</code> typo
</li><li>I don't know why, but the math following "It follows from Bessel's..." doesn't look right in the doc (the <code>:math:</code> directive is not parsed)
</li><li>Is \operatorname{bessel\_I}(\alpha, x) standard or should we just just the I sub whatever?
</li><li><code>`test_relation()`</code> needs to be in double back ticks or have a link to the appropriate place in the ref manual
</li><li>Trac tickets should use <code>:trac:</code> syntax
</li><li>Does <code>f(x) = Bessel(0): plot(f, (x, 1, 10))</code> work, or must one use <code>Bessel(0)(x)</code>? The example after that makes it look like maybe not...
</li><li>Bessel Y and Bessel K need a little filling out - and one of the <code>:math:</code> directives doesn't show up at all, the other isn't parsed right for some reason again
</li><li>I'd personally get rid of the whitespace changes in sage/functions/special.py - unlikely to have an effect, but not really necessary.
</li><li>How should we deal with the removal of the <code>"maxima"</code> and <code>"pari"</code> arguments? I'm not sure if it's really feasible to have a deprecation period for that, but we should discuss it.
</li><li>I suppose we don't need to keep <em>all</em> old tests, but some of them are rather different and might be worth putting in a TESTS section somewhere, just so that we don't have some unexpected regression only they catch.
</li><li>The switch to alpha from nu - I would rather not deprecate this either, but in principle someone could have used it as a keyword argument in the past...
</li></ul>
TicketkcrismanFri, 08 Feb 2013 18:14:01 GMTstatus changed; reviewer set
https://trac.sagemath.org/ticket/4102#comment:23
https://trac.sagemath.org/ticket/4102#comment:23
<ul>
<li><strong>status</strong>
changed from <em>new</em> to <em>needs_review</em>
</li>
<li><strong>reviewer</strong>
set to <em>Karl-Dieter Crisman</em>
</li>
</ul>
<p>
Here's the only failures I got with 5.7.beta3.
</p>
<pre class="wiki">sage -t "devel/sage-main/sage/calculus/desolvers.py"
**********************************************************************
File "/Users/.../sage-5.7.beta3/devel/sage-main/sage/calculus/desolvers.py", line 252:
sage: desolve(x^2*diff(y,x,x)+x*diff(y,x)+(x^2-4)*y==0,y)
Expected:
k1*bessel_j(2, x) + k2*bessel_y(2, x)
Got:
k1*bessel_J(2, x) + k2*bessel_Y(2, x)
**********************************************************************
1 items had failures:
1 of 62 in __main__.example_1
***Test Failed*** 1 failures.
[10.1 s]
</pre><p>
Hmm, should we keep the lowercase versions around, or was that actually an error that we never parsed those? Apparently it was pure Maxima output, looking at the old code, so just replace with the actual return value.
</p>
<pre class="wiki">sage -t "devel/sage-main/sage/calculus/wester.py"
**********************************************************************
File "/Users/.../sage-5.7.beta3/devel/sage-main/sage/calculus/wester.py", line 39:
sage: bessel_J (2, 1+I)
Expected:
0.0415798869439621 + 0.247397641513306*I
Got:
bessel_J(2, I + 1)
**********************************************************************
1 items had failures:
1 of 200 in __main__.example_0
***Test Failed*** 1 failures.
[4.4 s]
</pre><p>
Easy enough to fix - we could even add the <code>n()</code> version there. Actually, we probably should, since the test is probably testing for something - we'll have to just read that quick.
</p>
<pre class="wiki">sage -t "devel/sage-main/sage/functions/special.py"
**********************************************************************
File "/Users/.../sage-5.7.beta3/devel/sage-main/sage/functions/special.py", line 521:
sage: n(bessel_J(3,10,"maxima"))
Exception raised:
Traceback (most recent call last):
sage: n(bessel_J(3,10,"maxima"))
File "function.pyx", line 354, in sage.symbolic.function.Function.__call__ (sage/symbolic/function.cpp:3976)
TypeError: Symbolic function bessel_J takes exactly 2 arguments (3 given)
**********************************************************************
File "/Users/.../sage-5.7.beta3/devel/sage-main/sage/functions/special.py", line 536:
sage: n(bessel_J(3,10,"maxima"))
Exception raised:
n(bessel_J(Integer(3),Integer(10),"maxima"))###line 536:
sage: n(bessel_J(3,10,"maxima"))
File "function.pyx", line 354, in sage.symbolic.function.Function.__call__ (sage/symbolic/function.cpp:3976)
TypeError: Symbolic function bessel_J takes exactly 2 arguments (3 given)
**********************************************************************
2 items had failures:
1 of 5 in __main__.example_8
1 of 5 in __main__.example_9
***Test Failed*** 2 failures.
[3.8 s]
</pre><p>
Hmm, here is where that potential deprecation I mentioned might come in.
</p>
<pre class="wiki">sage -t "devel/sage-main/sage/symbolic/random_tests.py"
**********************************************************************
File "/Users/.../sage-5.7.beta3/devel/sage-main/sage/symbolic/random_tests.py", line 236:
sage: print "ignore this"; random_expr(50, nvars=3, coeff_generator=CDF.random_element) # random
Exception raised:
<snip>
File "misc.pyx", line 209, in sage.structure.misc.getattr_from_other_class (sage/structure/misc.c:1488)
AttributeError: 'sage.rings.complex_interval.ComplexIntervalFieldElement' object has no attribute 'arcsin'
**********************************************************************
</pre><p>
Apparently the usual craziness with random expression has reached new heights with these extra functions. I suggest we just try a different seed or something. Not every random expression will be meaningful, for instance.
</p>
TicketkcrismanFri, 08 Feb 2013 18:15:03 GMTstatus changed; work_issues set
https://trac.sagemath.org/ticket/4102#comment:24
https://trac.sagemath.org/ticket/4102#comment:24
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>needs_work</em>
</li>
<li><strong>work_issues</strong>
set to <em>doctest fixes, various minor documentation and other issues</em>
</li>
</ul>
<p>
Needs work:
</p>
<ul><li>doctest fixes, various minor documentation and other issues
</li></ul><p>
And needs review on the code itself :-)
</p>
<p>
But now it's really looking tractable to finish this off.
</p>
TicketbenjaminfjonesWed, 13 Feb 2013 07:06:17 GMTcc changed
https://trac.sagemath.org/ticket/4102#comment:25
https://trac.sagemath.org/ticket/4102#comment:25
<ul>
<li><strong>cc</strong>
<em>burcin</em> added
</li>
</ul>
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/4102#comment:22" title="Comment 22">kcrisman</a>:
</p>
<p>
Thanks for looking over the patch!
</p>
<blockquote class="citation">
<p>
Dumb comments since I don't have time for proper review - and more importantly, there are no obvious horrible things (though I haven't gone in depth with branches yet). If all this really works and there are no typos, I think this will be a VERY nice addition.
</p>
<ul><li><code>unqiue</code> typo
</li><li><code>Verfify</code> typo
</li><li><code>increasin</code> typo
</li><li>I don't know why, but the math following "It follows from Bessel's..." doesn't look right in the doc (the <code>:math:</code> directive is not parsed)
</li></ul></blockquote>
<p>
Fixed, it was a one space indentation problem.
</p>
<blockquote class="citation">
<ul><li>Is \operatorname{bessel\_I}(\alpha, x) standard or should we just just the I sub whatever?
</li></ul></blockquote>
<p>
I was unsure about this. I think now it makes most sense to just stick with I_\alpha when in a math block.
</p>
<blockquote class="citation">
<ul><li><code>`test_relation()`</code> needs to be in double back ticks or have a link to the appropriate place in the ref manual
</li><li>Trac tickets should use <code>:trac:</code> syntax
</li><li>Does <code>f(x) = Bessel(0): plot(f, (x, 1, 10))</code> work, or must one use <code>Bessel(0)(x)</code>? The example after that makes it look like maybe not...
</li></ul></blockquote>
<p>
The way the code works you have to specify the variable on the right hand side, e.g.:
</p>
<pre class="wiki">sage: f(x) = Bessel(0)(x)
sage: f(x) = bessel_I(0, x)
</pre><p>
This is because <code>Bessel()</code> returns lambda functions under the hood. Personally, I prefer having the variable dependence made explicit, but I'm open to suggestions if there are other
ways you can think of to get that functionality.
</p>
<blockquote class="citation">
<ul><li>Bessel Y and Bessel K need a little filling out - and one of the <code>:math:</code> directives doesn't show up at all, the other isn't parsed right for some reason again
</li></ul></blockquote>
<p>
I'll work on Bessel Y and K, I realize now that you mention it that I didn't fill in the definitions there :). Anyone with good doctest suggestions for these is welcome to chime in, I'll add the tests if you can think of interesting or relevant ones.
</p>
<blockquote class="citation">
<ul><li>I'd personally get rid of the whitespace changes in sage/functions/special.py - unlikely to have an effect, but not really necessary.
</li></ul></blockquote>
<p>
Yep, you're right.
</p>
<blockquote class="citation">
<ul><li>How should we deal with the removal of the <code>"maxima"</code> and <code>"pari"</code> arguments? I'm not sure if it's really feasible to have a deprecation period for that, but we should discuss it.
</li></ul></blockquote>
<p>
This is a question that's been troubling me. I don't know how to make the deprecation happen and make progress here without renaming the new functions and then swapping them in when the deprecation period is over. The infrastructure we have for adding symbolic functions (inheriting from <code>BuiltinFunction</code>, etc) doesn't support any kind of system arguments without overriding <code>call()</code>.
</p>
<p>
At least existing code that uses the Bessel functions as they are now in Sage won't break unless they explicitly use the system argument.
</p>
<p>
Maybe @burcin has a suggestion here?
</p>
<blockquote class="citation">
<ul><li>I suppose we don't need to keep <em>all</em> old tests, but some of them are rather different and might be worth putting in a TESTS section somewhere, just so that we don't have some unexpected regression only they catch.
</li></ul></blockquote>
<p>
Good point, I'll see what I can salvage.
</p>
<blockquote class="citation">
<ul><li>The switch to alpha from nu - I would rather not deprecate this either, but in principle someone could have used it as a keyword argument in the past...
</li></ul></blockquote>
<p>
It doesn't make a difference to me, I used alpha because that's what's on the wikipedia page :) Abramowitz & Stegun uses n or \nu and so does the mpmath documentation. I can easily switch \alpha to \nu with some editor-fu.
</p>
TicketbenjaminfjonesTue, 12 Mar 2013 20:47:19 GMTattachment set
https://trac.sagemath.org/ticket/4102
https://trac.sagemath.org/ticket/4102
<ul>
<li><strong>attachment</strong>
set to <em>trac_symbolic_bessel_doctests.patch</em>
</li>
</ul>
<p>
fix doctests and tutorial references involving Bessel function API
</p>
TicketbenjaminfjonesTue, 12 Mar 2013 20:51:54 GMTstatus changed; work_issues deleted
https://trac.sagemath.org/ticket/4102#comment:26
https://trac.sagemath.org/ticket/4102#comment:26
<ul>
<li><strong>status</strong>
changed from <em>needs_work</em> to <em>needs_review</em>
</li>
<li><strong>work_issues</strong>
<em>doctest fixes, various minor documentation and other issues</em> deleted
</li>
</ul>
<p>
I've uploaded two new patches addressing comments by @kcrisman. The two latest patches are finally ready for complete review.
</p>
<p>
Patchbot:
</p>
<p>
Apply trac_symbolic_bessel_v5.patch trac_symbolic_bessel_doctests.patch
</p>
TicketbenjaminfjonesTue, 12 Mar 2013 20:58:35 GMT
https://trac.sagemath.org/ticket/4102#comment:27
https://trac.sagemath.org/ticket/4102#comment:27
<p>
Some additional notes regarding your comments, @kcrisman:
</p>
<ul><li>The doctest of <code>desolve</code> that was failing was returning unconverted Maxima output, that's what the <code>bessel_j</code>, etc are. With the v5 patch we now have an honest Sage symbolic function as the return value in that case (also, see the diff eq doctest examples I wrote).
</li></ul><ul><li>I changes from using \alpha as the order to \nu for consistency with mpmath and Maxima.
</li></ul><ul><li>I changed the random expression seed to 53 (my favorite random integer) and that test no longer raises an exception.
</li></ul>
TicketkcrismanWed, 13 Mar 2013 16:11:51 GMT
https://trac.sagemath.org/ticket/4102#comment:28
https://trac.sagemath.org/ticket/4102#comment:28
<p>
Nice work. I do feel like we should ask on sage-devel about deprecating the evaluation system keywords versus (as in the current version) simply removing them but leaving room for their return...
</p>
<pre class="wiki">assert _system == 'mpmath'
</pre><p>
I suppose we could at least doctest this as a todo with the error message it receives with the "wrong" input.
</p>
<p>
I still want to give it a final go-over, but various testing of your tests and code makes me think this is ready. What a job!
</p>
TicketbenjaminfjonesTue, 26 Mar 2013 00:54:33 GMT
https://trac.sagemath.org/ticket/4102#comment:29
https://trac.sagemath.org/ticket/4102#comment:29
<p>
I spent some time today thinking about the deprecation issue. Here's my summary:
</p>
<p>
The current patches introduce two API changes. First, the new <code>bessel_I, bessel_J, etc</code> functions take two positional arguments whereas the old ones take 2 positional arguments and two optional keyword arguments (<code>algorithm</code> and <code>prec</code>). The second API change is the same change in arguments, but to the constructor <code>Bessel</code>.
</p>
<p>
I can add deprecation warnings to the <code>Bessel</code> constructor easily and have it call the old <code>bessel_?</code> functions during the deprecation period. On the other hand, I don't know how to implement deprecation for the old <code>bessel_?</code> functions. I can imagine trying to override <code>BuiltinFunction</code>'s call method, or turning the new <code>bessel_?</code> functions into wrappers which call the new ones if two arguments are used, and give a deprecation warning and call the old versions if more than 2 arguments are given.
</p>
<hr />
<p>
I can:
</p>
<ol><li>try to implement the deprecation
</li><li>ask on sage-devel for a waiver from the deprecation policy in this case
</li><li>other?
</li></ol><p>
What say you all?
</p>
TicketbenjaminfjonesTue, 26 Mar 2013 21:15:48 GMT
https://trac.sagemath.org/ticket/4102#comment:30
https://trac.sagemath.org/ticket/4102#comment:30
<p>
After chatting with @burcin, I decided to do 1. The new patch implements deprecation by retaining all the old code with names prefixed by an underscore. I preserved all the old doctests (which reference the underscored names). In the new code, I overrode <code>__call__</code> if more than 2 arguments are given.
</p>
<p>
Ready for review!
</p>
TicketbenjaminfjonesTue, 26 Mar 2013 21:18:05 GMT
https://trac.sagemath.org/ticket/4102#comment:31
https://trac.sagemath.org/ticket/4102#comment:31
<p>
Patchbot, apply trac_symbolic_bessel_v5.patch trac_symbolic_bessel_doctests.patch trac_symbolic_bessel_deprecation.patch
</p>
TicketkcrismanWed, 27 Mar 2013 01:11:51 GMT
https://trac.sagemath.org/ticket/4102#comment:32
https://trac.sagemath.org/ticket/4102#comment:32
<p>
Can you remind me what the plan was for algorithm as a keyword? Wasn't there some plan to <em>re</em>introduce it once we got the hooks in properly, so that people could easily compare e.g. Pari, mpmath, Mma (if available), etc.? Doesn't mean this patch couldn't go in, just trying to get things straight.
</p>
<p>
Quick glance at the latest patch looks good. What a lot of underscores; did you write a script?
</p>
TicketbenjaminfjonesWed, 27 Mar 2013 01:32:20 GMT
https://trac.sagemath.org/ticket/4102#comment:33
https://trac.sagemath.org/ticket/4102#comment:33
<p>
The algorithm keyword in _eval_ requires a work in progress branch of pynac that has probably bit rot by now. I have it on my agenda (since last year!) to look back into it..
</p>
TicketkcrismanWed, 27 Mar 2013 01:39:12 GMT
https://trac.sagemath.org/ticket/4102#comment:34
https://trac.sagemath.org/ticket/4102#comment:34
<p>
Right, I understand - my point is that maybe the deprecation message should be slightly different, something like
</p>
<pre class="wiki">deprecation(4102, 'precision argument is deprecated\nalgorithm argument will only be available as a named keyword in the future and is currently in mothballs')
</pre><p>
or something somewhat more professional/accurate than that.
</p>
TicketbenjaminfjonesWed, 27 Mar 2013 17:13:58 GMT
https://trac.sagemath.org/ticket/4102#comment:35
https://trac.sagemath.org/ticket/4102#comment:35
<p>
I see, sure, how about just:
</p>
<p>
"precision argument is deprecated, algorithm argument is currently deprecated, but will be available as a named keyword in the future"
</p>
TicketkcrismanWed, 27 Mar 2013 17:29:40 GMT
https://trac.sagemath.org/ticket/4102#comment:36
https://trac.sagemath.org/ticket/4102#comment:36
<blockquote class="citation">
<p>
I see, sure, how about just:
"precision argument is deprecated, algorithm argument is currently deprecated, but will be available as a named keyword in the future"
</p>
</blockquote>
<p>
That sounds good, except that I would put a semicolon instead of a comma in the first comma spot.
</p>
TicketbenjaminfjonesWed, 27 Mar 2013 19:26:51 GMTattachment set
https://trac.sagemath.org/ticket/4102
https://trac.sagemath.org/ticket/4102
<ul>
<li><strong>attachment</strong>
set to <em>trac_symbolic_bessel_deprecation.patch</em>
</li>
</ul>
<p>
add deprecation of old API
</p>
TicketbenjaminfjonesThu, 28 Mar 2013 00:08:11 GMTattachment set
https://trac.sagemath.org/ticket/4102
https://trac.sagemath.org/ticket/4102
<ul>
<li><strong>attachment</strong>
set to <em>trac_symbolic_bessel_v5.patch</em>
</li>
</ul>
<p>
latest symbolic Bessel functions patch, ready for review
</p>
TicketbenjaminfjonesThu, 28 Mar 2013 00:09:06 GMT
https://trac.sagemath.org/ticket/4102#comment:37
https://trac.sagemath.org/ticket/4102#comment:37
<p>
Latest attachment makes a tiny doc change to fix a latex mistake.
</p>
TicketbenjaminfjonesFri, 29 Mar 2013 22:47:44 GMT
https://trac.sagemath.org/ticket/4102#comment:38
https://trac.sagemath.org/ticket/4102#comment:38
<p>
Patchbot apply trac_symbolic_bessel_v5.patch trac_symbolic_bessel_doctests.patch trac_symbolic_bessel_deprecation.patch
</p>
TicketvbraunMon, 01 Apr 2013 20:55:00 GMT
https://trac.sagemath.org/ticket/4102#comment:39
https://trac.sagemath.org/ticket/4102#comment:39
<p>
Patchbot shows test failures on sage-5.9.beta2
</p>
TicketkcrismanTue, 02 Apr 2013 00:36:11 GMT
https://trac.sagemath.org/ticket/4102#comment:40
https://trac.sagemath.org/ticket/4102#comment:40
<blockquote class="citation">
<p>
Patchbot shows test failures on sage-5.9.beta2
</p>
</blockquote>
<p>
In particular, they are relevant:
</p>
<pre class="wiki">sage -t sage/functions/bessel.py
**********************************************************************
File "sage/functions/bessel.py", line 977, in sage.functions.bessel.Bessel
Failed example:
f = desolve(diffeq, y, [1, 1, 1]); f
Expected:
(bessel_J(0, 1) + bessel_J(1, 1))*bessel_Y(0, x)/(bessel_Y(0, 1)*bessel_J(1, 1) - bessel_Y(1, 1)*bessel_J(0, 1)) - (bessel_Y(0, 1) + bessel_Y(1, 1))*bessel_J(0, x)/(bessel_Y(0, 1)*bessel_J(1, 1) - bessel_Y(1, 1)*bessel_J(0, 1))
Got:
(bessel_Y(0, 1) + bessel_Y(1, 1))*bessel_j(0, x)/(bessel_j(0, 1)*bessel_Y(1, 1) - bessel_j(1, 1)*bessel_Y(0, 1)) - (bessel_j(0, 1) + bessel_j(1, 1))*bessel_Y(0, x)/(bessel_j(0, 1)*bessel_Y(1, 1) - bessel_j(1, 1)*bessel_Y(0, 1))
**********************************************************************
File "sage/functions/bessel.py", line 983, in sage.functions.bessel.Bessel
Failed example:
fp.subs(x=1).n()
Exception raised:
Traceback (most recent call last):
File "/mnt/storage2TB/patchbot/Sage/sage-5.9.beta2/local/lib/python2.7/site-packages/sage/doctest/forker.py", line 460, in _run
self.execute(example, compiled, test.globs)
File "/mnt/storage2TB/patchbot/Sage/sage-5.9.beta2/local/lib/python2.7/site-packages/sage/doctest/forker.py", line 819, in execute
exec compiled in globs
File "<doctest sage.functions.bessel.Bessel[29]>", line 1, in <module>
fp.subs(x=Integer(1)).n()
File "expression.pyx", line 4381, in sage.symbolic.expression.Expression._numerical_approx (sage/symbolic/expression.cpp:21011)
TypeError: cannot evaluate symbolic expression numerically
**********************************************************************
1 item had failures:
2 of 46 in sage.functions.bessel.Bessel
[258 tests, 2 failures, 16.6 s]
----------------------------------------------------------------------
sage -t sage/functions/bessel.py # 2 doctests failed
----------------------------------------------------------------------
</pre><p>
I don't like that some are lowercase and some uppercase. I think that the second error is just a result of that - the derivative won't function properly.
</p>
TicketbenjaminfjonesTue, 02 Apr 2013 04:46:31 GMT
https://trac.sagemath.org/ticket/4102#comment:41
https://trac.sagemath.org/ticket/4102#comment:41
<p>
There is something strange going on. Here is sage-5.9.beta2 with the three patches applied:
</p>
<pre class="wiki">[bjones@cabbage:devel/sage]% ../../sage
----------------------------------------------------------------------
| Sage Version 5.9.beta2, Release Date: 2013-03-28 |
| Type "notebook()" for the browser-based notebook interface. |
| Type "help()" for help. |
----------------------------------------------------------------------
**********************************************************************
* *
* Warning: this is a prerelease version, and it may be unstable. *
* *
**********************************************************************
sage: y = function('y', x)
sage: diffeq = x^2*diff(y,x,x) + x*diff(y,x) + x^2*y == 0
sage: f = desolve(diffeq, y, [1, 1, 1]); f
(bessel_Y(0, 1) + bessel_Y(1, 1))*bessel_J(0, x)/(bessel_J(0, 1)*bessel_Y(1, 1) - bessel_J(1, 1)*bessel_Y(0, 1)) - (bessel_J(0, 1) + bessel_J(1, 1))*bessel_Y(0, x)/(bessel_J(0, 1)*bessel_Y(1, 1) - bessel_J(1, 1)*bessel_Y(0, 1))
</pre><p>
which is exactly what the doctest expects.
</p>
<p>
Now doctesting <code>sage/functions/bessel.py</code> with sage in the exact same state:
</p>
<pre class="wiki">[bjones@cabbage:devel/sage]% ../../sage -t sage/functions/bessel.py
Running doctests with ID 2013-04-01-21-31-17-4bc246be.
Doctesting 1 file.
sage -t sage/functions/bessel.py
**********************************************************************
File "sage/functions/bessel.py", line 977, in sage.functions.bessel.Bessel
Failed example:
f = desolve(diffeq, y, [1, 1, 1]); f
Expected:
(bessel_J(0, 1) + bessel_J(1, 1))*bessel_Y(0, x)/(bessel_Y(0, 1)*bessel_J(1, 1) - bessel_Y(1, 1)*bessel_J(0, 1)) - (bessel_Y(0, 1) + bessel_Y(1, 1))*bessel_J(0, x)/(bessel_Y(0, 1)*bessel_J(1, 1) - bessel_Y(1, 1)*bessel_J(0, 1))
Got:
(bessel_Y(0, 1) + bessel_Y(1, 1))*bessel_j(0, x)/(bessel_j(0, 1)*bessel_Y(1, 1) - bessel_j(1, 1)*bessel_Y(0, 1)) - (bessel_j(0, 1) + bessel_j(1, 1))*bessel_Y(0, x)/(bessel_j(0, 1)*bessel_Y(1, 1) - bessel_j(1, 1)*bessel_Y(0, 1))
</pre><p>
The lower cased <code>bessel_j</code> is what Maxima returns if you don't register a conversion to <code>bessel_J</code>, the Sage symbolic version of J that these patches introduce.
</p>
<p>
What is also strange is that the above output does actually represent a different form of the correct solution (modulo replacing bessel_j by bessel_J).
</p>
<p>
So what is going on here?
</p>
<p>
FWIW, sage-5.8 with same three patches applied does not exhibit this behavior.
</p>
TicketvbraunTue, 02 Apr 2013 08:29:40 GMT
https://trac.sagemath.org/ticket/4102#comment:42
https://trac.sagemath.org/ticket/4102#comment:42
<p>
Maxima is the same version in sage-5.8 and 5.9.beta2, so thats not it.
</p>
<p>
The new doctesting framework was introduced in sage-5.9.beta, thats a likely suspect. It uses fork, so external interfaces need to be shut down / restarted. Perhaps the restarted maxima process is not set up correctly? Though just using <code>@fork</code> seems to work.
</p>
TicketjdemeyerFri, 05 Apr 2013 15:43:40 GMT
https://trac.sagemath.org/ticket/4102#comment:43
https://trac.sagemath.org/ticket/4102#comment:43
<p>
benjaminfjones: I don't understand the problem. It seems to me that the doctest should simply be changed to match the "correct" output.
</p>
TicketbenjaminfjonesFri, 05 Apr 2013 16:00:00 GMT
https://trac.sagemath.org/ticket/4102#comment:44
https://trac.sagemath.org/ticket/4102#comment:44
<p>
So the correct output is:
</p>
<pre class="wiki">(bessel_J(0, 1) + bessel_J(1, 1))*bessel_Y(0, x)/(bessel_Y(0, 1)*bessel_J(1, 1) - bessel_Y(1, 1)*bessel_J(0, 1)) - (bessel_Y(0, 1) + bessel_Y(1, 1))*bessel_J(0, x)/(bessel_Y(0, 1)*bessel_J(1, 1) - bessel_Y(1, 1)*bessel_J(0, 1))
</pre><p>
that is both mathematically correct and what you get when you apply the patches, run sage, and execute the commands manually.
</p>
<p>
The problem is that when you <strong>doctest</strong> the same exact commands in the same exact sage, the output that comes back is different in two ways (explained in the comment above).
</p>
TicketbenjaminfjonesFri, 05 Apr 2013 16:58:54 GMT
https://trac.sagemath.org/ticket/4102#comment:45
https://trac.sagemath.org/ticket/4102#comment:45
<p>
More clues: (?)
</p>
<p>
Here are the three commands in question
</p>
<pre class="wiki">sage: y = function('y', x)
sage: diffeq = x^2*diff(y,x,x) + x*diff(y,x) + x^2*y == 0
sage: f = desolve(diffeq, y, [1, 1, 1]); f
</pre><ol><li>running the commands in an interactive sage session directly after startup, output is:
</li></ol><pre class="wiki">(bessel_Y(0, 1) + bessel_Y(1, 1))*bessel_J(0, x)/(bessel_J(0, 1)*bessel_Y(1, 1) - bessel_J(1, 1)*bessel_Y(0, 1)) - (bessel_J(0, 1) + bessel_J(1, 1))*bessel_Y(0, x)/(bessel_J(0, 1)*bessel_Y(1, 1) - bessel_J(1, 1)*bessel_Y(0, 1))
</pre><ol start="2"><li>running the same commands as included in a doctest in <code>sage/functions/bessel.py</code>, output is:
</li></ol><pre class="wiki">(bessel_Y(0, 1) + bessel_Y(1, 1))*bessel_j(0, x)/(bessel_j(0, 1)*bessel_Y(1, 1) - bessel_j(1, 1)*bessel_Y(0, 1)) - (bessel_j(0, 1) + bessel_j(1, 1))*bessel_Y(0, x)/(bessel_j(0, 1)*bessel_Y(1, 1) - bessel_j(1, 1)*bessel_Y(0, 1))
</pre><ol start="3"><li>putting the three commands in a docstring alone in a new file <code>foo.py</code> and doctesting that, output is:
</li></ol><pre class="wiki">(bessel_Y(0, 1) + bessel_Y(1, 1))*bessel_J(0, x)/(bessel_J(0, 1)*bessel_Y(1, 1) - bessel_J(1, 1)*bessel_Y(0, 1)) - (bessel_J(0, 1) + bessel_J(1, 1))*bessel_Y(0, x)/(bessel_J(0, 1)*bessel_Y(1, 1) - bessel_J(1, 1)*bessel_Y(0, 1))
</pre><p>
note: same output as in (1)
</p>
<p>
So it looks like there is some hidden state affecting the doctesting in scenario (2).
</p>
TicketjdemeyerTue, 09 Apr 2013 12:28:41 GMT
https://trac.sagemath.org/ticket/4102#comment:46
https://trac.sagemath.org/ticket/4102#comment:46
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/4102#comment:45" title="Comment 45">benjaminfjones</a>:
</p>
<blockquote class="citation">
<p>
So it looks like there is some hidden state affecting the doctesting in scenario (2).
</p>
</blockquote>
<p>
The doctests which are run <em>before</em> that test are extra "state".
</p>
TicketkcrismanThu, 25 Apr 2013 02:21:45 GMT
https://trac.sagemath.org/ticket/4102#comment:47
https://trac.sagemath.org/ticket/4102#comment:47
<p>
See also <a class="closed ticket" href="https://trac.sagemath.org/ticket/2516" title="enhancement: generalized hypergeometric functions should be implemented (closed: fixed)">#2516</a>.
</p>
TicketbenjaminfjonesMon, 20 May 2013 23:22:14 GMTattachment set
https://trac.sagemath.org/ticket/4102
https://trac.sagemath.org/ticket/4102
<ul>
<li><strong>attachment</strong>
set to <em>trac_symbolic_bessel_apply.sh</em>
</li>
</ul>
<p>
Copy of trac_symbolic_bessel_v5, minus one doctest block
</p>
TicketbenjaminfjonesMon, 20 May 2013 23:23:06 GMTattachment set
https://trac.sagemath.org/ticket/4102
https://trac.sagemath.org/ticket/4102
<ul>
<li><strong>attachment</strong>
set to <em>trac_symbolic_bessel_v6.patch</em>
</li>
</ul>
<p>
Copy of trac_symbolic_bessel_v5, minus one doctest block
</p>
TicketbenjaminfjonesMon, 20 May 2013 23:33:58 GMTdescription changed
https://trac.sagemath.org/ticket/4102#comment:48
https://trac.sagemath.org/ticket/4102#comment:48
<ul>
<li><strong>description</strong>
modified (<a href="/ticket/4102?action=diff&version=48">diff</a>)
</li>
</ul>
<p>
I still have not been able to track down the doctesting issue (described starting at <a class="ticket" href="https://trac.sagemath.org/ticket/4102#comment:41" title="Comment 41">comment:41</a>). I've tried bisecting the doctest state (delta debugging) to no avail. The problem seems to be intimately linked to the doctesting environment. I'm unable to reproduce the doctest failure when running <span class="underline">all</span> the prior doctests which come before in <code>bessel.py</code>, in the right order, by hand, and then running the offending one.
</p>
<p>
The only thing I can tell for sure is that at some point as the doctests are run, one of the pynac symbol tables get's modified. This causes the <code>bessel_j</code> vs <code>bessel_J</code> problem.
</p>
<p>
My inclination is to remove the offending doctest and file a new ticket to resolve the problem. Meanwhile, the bessel function code can be reviewed and become useful. I've posted a patch <code>trac_symbolic_bessel_v6</code> which removes the offending doctest block.
</p>
<p>
Comments?
</p>
<hr />
<p>
Patchbot, apply trac_symbolic_bessel_v6.patch trac_symbolic_bessel_doctests.patch trac_symbolic_bessel_deprecation.patch
</p>
TicketbenjaminfjonesMon, 27 May 2013 16:58:09 GMT
https://trac.sagemath.org/ticket/4102#comment:49
https://trac.sagemath.org/ticket/4102#comment:49
<p>
Tests are passing on 5.10.beta4. The startup time plugin is failing, however. Should we lazy import here? Also how about lazy import for all the special functions (the idea being that relatively few users will need any given special function)?
</p>
TicketburcinMon, 27 May 2013 17:09:42 GMT
https://trac.sagemath.org/ticket/4102#comment:50
https://trac.sagemath.org/ticket/4102#comment:50
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/4102#comment:49" title="Comment 49">benjaminfjones</a>:
</p>
<blockquote class="citation">
<p>
Tests are passing on 5.10.beta4. The startup time plugin is failing, however. Should we lazy import here? Also how about lazy import for all the special functions (the idea being that relatively few users will need any given special function)?
</p>
</blockquote>
<p>
+100 to lazy import for all special functions, but in a separate ticket.
</p>
<p>
It would be great if you can use lazy import for the functions defined here to silence the startup time plugin.
</p>
<p>
About the doctesting framework issue: I briefly tried to debug this and didn't get anywhere either. I agree that we should move this to a new ticket and not hold this one up longer. Instead of removing the test, can you mark it <code># not tested</code> and mention the ticket number?
</p>
<p>
Thanks a lot for your work on this.
</p>
TicketvbraunMon, 27 May 2013 18:49:37 GMT
https://trac.sagemath.org/ticket/4102#comment:51
https://trac.sagemath.org/ticket/4102#comment:51
<p>
I'm trying to understand how the interfacing works. Is this the intended output?
</p>
<pre class="wiki">sage: maxima(bessel_I).sage()
bessel_i
</pre>
TicketvbraunMon, 27 May 2013 19:07:37 GMT
https://trac.sagemath.org/ticket/4102#comment:52
https://trac.sagemath.org/ticket/4102#comment:52
<p>
<code>maxima_function()</code>, used in <code>sage.functions.bessel._bessel_J</code>, overwrites the symbol table entry:
</p>
<pre class="wiki">sage: from sage.functions.special import maxima_function
sage: type(sage.symbolic.pynac.symbol_table['maxima']['bessel_j'])
<class 'sage.functions.bessel.Function_Bessel_J'>
sage: maxima_function('bessel_j')
bessel_j
sage: type(sage.symbolic.pynac.symbol_table['maxima']['bessel_j'])
<class 'sage.functions.special.NewMaximaFunction'>
</pre>
TicketbenjaminfjonesTue, 28 May 2013 16:55:59 GMT
https://trac.sagemath.org/ticket/4102#comment:53
https://trac.sagemath.org/ticket/4102#comment:53
<p>
@burcin: Okay! Good idea. I'll lazy import the Bessel stuff and create a new ticket for the rest.
</p>
<p>
@vbraun: Thanks! That's good detective work. How did you figure that out (I wasted a lot of time trying to find the culprit)?
</p>
<hr />
<p>
I'll look into addressing the symbol table issue and report back with updated patches.
</p>
TicketvbraunTue, 28 May 2013 17:03:08 GMT
https://trac.sagemath.org/ticket/4102#comment:54
https://trac.sagemath.org/ticket/4102#comment:54
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/4102#comment:53" title="Comment 53">benjaminfjones</a>:
</p>
<blockquote class="citation">
<p>
@vbraun: Thanks! That's good detective work. How did you figure that out
</p>
</blockquote>
<p>
You better sit down for this one ;-)
</p>
<pre class="wiki">$ grep bessel_j sage/functions/*
</pre>
TicketbenjaminfjonesTue, 28 May 2013 17:17:07 GMT
https://trac.sagemath.org/ticket/4102#comment:55
https://trac.sagemath.org/ticket/4102#comment:55
<p>
Damn.
</p>
TicketeviatarbachTue, 28 May 2013 22:24:24 GMTcc changed
https://trac.sagemath.org/ticket/4102#comment:56
https://trac.sagemath.org/ticket/4102#comment:56
<ul>
<li><strong>cc</strong>
<em>eviatarbach</em> added
</li>
</ul>
TicketkcrismanTue, 11 Jun 2013 17:59:19 GMTstatus changed
https://trac.sagemath.org/ticket/4102#comment:57
https://trac.sagemath.org/ticket/4102#comment:57
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>needs_work</em>
</li>
</ul>
<p>
Just updating status due to the last few comments. This would be really good to have ready to review at Sage Days 48/Edu Days 5 next week.
</p>
TicketeviatarbachFri, 14 Jun 2013 01:16:24 GMT
https://trac.sagemath.org/ticket/4102#comment:58
https://trac.sagemath.org/ticket/4102#comment:58
<p>
This would be nice for my GSoC project as well.
</p>
TicketbenjaminfjonesFri, 14 Jun 2013 01:20:11 GMT
https://trac.sagemath.org/ticket/4102#comment:59
https://trac.sagemath.org/ticket/4102#comment:59
<p>
OK, I'll try to set aside some time for this tomorrow (or weekend).
</p>
TicketeviatarbachFri, 14 Jun 2013 01:31:52 GMT
https://trac.sagemath.org/ticket/4102#comment:60
https://trac.sagemath.org/ticket/4102#comment:60
<p>
Thank you! That would be great :)
</p>
TicketbenjaminfjonesSat, 15 Jun 2013 05:25:41 GMTattachment set
https://trac.sagemath.org/ticket/4102
https://trac.sagemath.org/ticket/4102
<ul>
<li><strong>attachment</strong>
set to <em>trac_symbolic_bessel_v7.patch</em>
</li>
</ul>
<p>
adds bessel.py, lazy imports in all.py
</p>
TicketbenjaminfjonesSat, 15 Jun 2013 05:26:15 GMTattachment set
https://trac.sagemath.org/ticket/4102
https://trac.sagemath.org/ticket/4102
<ul>
<li><strong>attachment</strong>
set to <em>trac_symbolic_bessel_v7-doctests.patch</em>
</li>
</ul>
<p>
fixes/updates doctests external to sage/functions/bessel.py
</p>
TicketbenjaminfjonesSat, 15 Jun 2013 05:33:06 GMTstatus, description changed
https://trac.sagemath.org/ticket/4102#comment:61
https://trac.sagemath.org/ticket/4102#comment:61
<ul>
<li><strong>status</strong>
changed from <em>needs_work</em> to <em>needs_review</em>
</li>
<li><strong>description</strong>
modified (<a href="/ticket/4102?action=diff&version=61">diff</a>)
</li>
</ul>
<p>
OK, uploaded two new patches which:
</p>
<ol><li>address the problem raised in <a class="ticket" href="https://trac.sagemath.org/ticket/4102#comment:41" title="Comment 41">comment:41</a>, solution is to replace construction of a new <code>MaximaFunction</code> object (which alters the symbol table) to construcing and evaluating the function directly inside Maxima using <code>maxima.function()</code>.
</li><li>change Bessel imports in <code>sage/functions/all.py</code> to lazy imports
</li></ol><p>
Doctests in all the touched files pass, I'll wait for the patchbot to see about the rest.
</p>
<p>
Hope y'all at Sage Days have a chance to review the patches.
</p>
<hr />
<p>
Patchbot, apply trac_symbolic_bessel_v7.patch trac_symbolic_bessel_v7-doctests.patch
</p>
TicketbenjaminfjonesSat, 15 Jun 2013 17:13:47 GMTstatus changed
https://trac.sagemath.org/ticket/4102#comment:62
https://trac.sagemath.org/ticket/4102#comment:62
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>needs_work</em>
</li>
</ul>
<p>
There is another problem in <code>sage/calculus/desolvers.py</code>, I'm looking into it now.
</p>
TicketbenjaminfjonesSat, 15 Jun 2013 17:27:29 GMT
https://trac.sagemath.org/ticket/4102#comment:63
https://trac.sagemath.org/ticket/4102#comment:63
<p>
When a symbolic function is lazily imported, its constructor isn't called until the function is referenced and the constructor is responsible for populating the symbol tables that make conversion work (e.g. maxima <-> sage). So with lazy importing here, if I start up Sage and call <code>desolve</code> with Bessel's diffeq, we don't properly convert the result from Maxima to Sage because the Bessel functions are not in the symbol table (they haven't been constructed yet).
</p>
<p>
Any thoughts on this?
</p>
<p>
One idea I had is that we can register the conversions somewhere else (not in the constructors). But that would mean maintaining each symbolic function's code and its conversions in separate places (seems like a bad idea).
</p>
<p>
Another idea: import from sage.functions.bessel strictly (i.e. not lazily), but in bessel.py use lazy imports for everything that's not needed in the constructors.
</p>
TicketbenjaminfjonesSat, 15 Jun 2013 17:36:41 GMT
https://trac.sagemath.org/ticket/4102#comment:64
https://trac.sagemath.org/ticket/4102#comment:64
<p>
I think my preference would be to put 'lazy import symbolic functions' off to another ticket. We can discuss the issues involved there. Meanwhile, this can be reviewed.
</p>
TicketbenjaminfjonesSun, 16 Jun 2013 01:21:59 GMTattachment set
https://trac.sagemath.org/ticket/4102
https://trac.sagemath.org/ticket/4102
<ul>
<li><strong>attachment</strong>
set to <em>trac_symbolic_bessel_v7.2.patch</em>
</li>
</ul>
TicketbenjaminfjonesSun, 16 Jun 2013 01:24:01 GMTstatus, description changed
https://trac.sagemath.org/ticket/4102#comment:65
https://trac.sagemath.org/ticket/4102#comment:65
<ul>
<li><strong>status</strong>
changed from <em>needs_work</em> to <em>needs_review</em>
</li>
<li><strong>description</strong>
modified (<a href="/ticket/4102?action=diff&version=65">diff</a>)
</li>
</ul>
<p>
I removed the lazy import.
</p>
<p>
Ready for review!
</p>
<hr />
<p>
Patchbot apply trac_symbolic_bessel_v7.2.patch trac_symbolic_bessel_v7-doctests.patch
</p>
TicketeviatarbachMon, 17 Jun 2013 19:26:49 GMT
https://trac.sagemath.org/ticket/4102#comment:66
https://trac.sagemath.org/ticket/4102#comment:66
<p>
Thanks, I'm looking at it now.
</p>
<p>
Can I just remove all the assertions in <code>Bessel</code>? Some of them are redundant and I'm not sure why it's asserting that the order is real.
</p>
TicketeviatarbachMon, 17 Jun 2013 21:34:56 GMT
https://trac.sagemath.org/ticket/4102#comment:67
https://trac.sagemath.org/ticket/4102#comment:67
<p>
Here's what I changed:
</p>
<ul><li>Added documentation to the manuals
</li><li>Fixed a <code>bessel_K</code> identity that was incorrect
</li><li>Added <a class="missing wiki">SymPy?</a> conversions
</li><li>Minor formatting changes
</li><li>Removed assertions (I'll add them back if they were necessary)
</li><li>"for an arbitrary real number <code>\nu</code> (the order)" > "for an arbitrary complex number <code>\nu</code> (the order)"
</li></ul><p>
Looks good otherwise!
</p>
TicketeviatarbachMon, 17 Jun 2013 21:36:06 GMTattachment set
https://trac.sagemath.org/ticket/4102
https://trac.sagemath.org/ticket/4102
<ul>
<li><strong>attachment</strong>
set to <em>bessel_2.patch</em>
</li>
</ul>
TicketbenjaminfjonesMon, 17 Jun 2013 22:10:49 GMT
https://trac.sagemath.org/ticket/4102#comment:68
https://trac.sagemath.org/ticket/4102#comment:68
<p>
Thanks, those changes all look fine. The assertions aren't necessary, I should have removed them.
</p>
<hr />
<p>
Patchbot apply trac_symbolic_bessel_v7.2.patch trac_symbolic_bessel_v7-doctests.patch bessel_2.patch
</p>
TicketeviatarbachMon, 17 Jun 2013 22:33:22 GMT
https://trac.sagemath.org/ticket/4102#comment:69
https://trac.sagemath.org/ticket/4102#comment:69
<p>
Great. I just noticed that it was already in the manuals though. New patch.
</p>
<hr />
<p>
Patchbot apply trac_symbolic_bessel_v7.2.patch trac_symbolic_bessel_v7-doctests.patch bessel_2.2.patch
</p>
TicketeviatarbachMon, 17 Jun 2013 22:34:01 GMTattachment set
https://trac.sagemath.org/ticket/4102
https://trac.sagemath.org/ticket/4102
<ul>
<li><strong>attachment</strong>
set to <em>bessel_2.2.patch</em>
</li>
</ul>
TicketburcinMon, 17 Jun 2013 22:49:10 GMTreviewer, description, author changed; keywords set
https://trac.sagemath.org/ticket/4102#comment:70
https://trac.sagemath.org/ticket/4102#comment:70
<ul>
<li><strong>keywords</strong>
<em>sd48</em> added
</li>
<li><strong>reviewer</strong>
changed from <em>Karl-Dieter Crisman</em> to <em>Karl-Dieter Crisman, Burcin Erocal</em>
</li>
<li><strong>description</strong>
modified (<a href="/ticket/4102?action=diff&version=70">diff</a>)
</li>
<li><strong>author</strong>
changed from <em>Benjamin Jones</em> to <em>Benjamin Jones, Eviatar Bach, Volker Braun</em>
</li>
</ul>
<p>
All patches look good to me. We can switch this to positive review once the patchbot gives it a green light.
</p>
TicketkcrismanTue, 18 Jun 2013 04:43:10 GMT
https://trac.sagemath.org/ticket/4102#comment:71
https://trac.sagemath.org/ticket/4102#comment:71
<p>
Nice work! A lot of the thing Eviatar fixed were exactly the things I was thinking about on the train. Good stuff. Patchbot doesn't seem to be using the right patch, so:
</p>
<p>
Patchbot apply trac_symbolic_bessel_v7.2.patch trac_symbolic_bessel_v7-doctests.patch bessel_2.2.patch
</p>
TicketkcrismanTue, 18 Jun 2013 17:20:20 GMTstatus changed
https://trac.sagemath.org/ticket/4102#comment:72
https://trac.sagemath.org/ticket/4102#comment:72
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>needs_work</em>
</li>
</ul>
<p>
This passes all tests for me.
</p>
TicketkcrismanTue, 18 Jun 2013 17:20:36 GMTstatus changed
https://trac.sagemath.org/ticket/4102#comment:73
https://trac.sagemath.org/ticket/4102#comment:73
<ul>
<li><strong>status</strong>
changed from <em>needs_work</em> to <em>positive_review</em>
</li>
</ul>
TicketjdemeyerWed, 19 Jun 2013 06:41:30 GMTstatus changed
https://trac.sagemath.org/ticket/4102#comment:74
https://trac.sagemath.org/ticket/4102#comment:74
<ul>
<li><strong>status</strong>
changed from <em>positive_review</em> to <em>needs_work</em>
</li>
</ul>
<p>
I get several doctest failures:
</p>
<pre class="wiki">sage -t --long devel/sage/sage/functions/bessel.py
**********************************************************************
File "devel/sage/sage/functions/bessel.py", line 101, in sage.functions.bessel
Failed example:
bessel_J(0, x).diff(x)
Expected:
1/2*bessel_J(-1, x) - 1/2*bessel_J(1, x)
Got:
-1/2*bessel_J(1, x) + 1/2*bessel_J(-1, x)
**********************************************************************
File "devel/sage/sage/functions/bessel.py", line 248, in sage.functions.bessel.Function_Bessel_J
Failed example:
f.diff(x)
Expected:
1/2*bessel_J(1, x) - 1/2*bessel_J(3, x)
Got:
-1/2*bessel_J(3, x) + 1/2*bessel_J(1, x)
**********************************************************************
File "devel/sage/sage/functions/bessel.py", line 357, in sage.functions.bessel.Function_Bessel_J._derivative_
Failed example:
derivative(f, z)
Expected:
z |--> 1/2*bessel_J(9, z) - 1/2*bessel_J(11, z)
Got:
z |--> -1/2*bessel_J(11, z) + 1/2*bessel_J(9, z)
**********************************************************************
</pre><p>
(and various similar failures)
</p>
TicketjdemeyerWed, 19 Jun 2013 06:42:24 GMTdependencies set
https://trac.sagemath.org/ticket/4102#comment:75
https://trac.sagemath.org/ticket/4102#comment:75
<ul>
<li><strong>dependencies</strong>
set to <em>#9880</em>
</li>
</ul>
<p>
Perhaps this is due to <a class="closed ticket" href="https://trac.sagemath.org/ticket/9880" title="defect: Pynac comparison functions do not provide a SWO (closed: fixed)">#9880</a>.
</p>
TicketburcinWed, 19 Jun 2013 14:43:46 GMTattachment set
https://trac.sagemath.org/ticket/4102
https://trac.sagemath.org/ticket/4102
<ul>
<li><strong>attachment</strong>
set to <em>trac_4102-bessel_doctest_fixes.patch</em>
</li>
</ul>
TicketburcinWed, 19 Jun 2013 14:45:49 GMTstatus, description changed
https://trac.sagemath.org/ticket/4102#comment:76
https://trac.sagemath.org/ticket/4102#comment:76
<ul>
<li><strong>status</strong>
changed from <em>needs_work</em> to <em>needs_review</em>
</li>
<li><strong>description</strong>
modified (<a href="/ticket/4102?action=diff&version=76">diff</a>)
</li>
</ul>
<p>
I uploaded a new patch to fix doctest failures caused by <a class="closed ticket" href="https://trac.sagemath.org/ticket/9880" title="defect: Pynac comparison functions do not provide a SWO (closed: fixed)">#9880</a>.
</p>
TicketkcrismanWed, 19 Jun 2013 20:55:12 GMTstatus changed
https://trac.sagemath.org/ticket/4102#comment:77
https://trac.sagemath.org/ticket/4102#comment:77
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>positive_review</em>
</li>
</ul>
<p>
Looks good and passes tests.
</p>
TicketjdemeyerThu, 20 Jun 2013 19:53:46 GMTstatus changed
https://trac.sagemath.org/ticket/4102#comment:78
https://trac.sagemath.org/ticket/4102#comment:78
<ul>
<li><strong>status</strong>
changed from <em>positive_review</em> to <em>needs_work</em>
</li>
</ul>
<p>
On <code>silius</code> (ia64):
</p>
<pre class="wiki">sage -t --long devel/sage/sage/functions/bessel.py
**********************************************************************
File "devel/sage/sage/functions/bessel.py", line 258, in sage.functions.bessel.Function_Bessel_J
Failed example:
A[0]
Expected:
0.44005058574493355
Got:
0.44005058574493366
**********************************************************************
</pre>
TicketeviatarbachThu, 20 Jun 2013 20:16:23 GMTattachment set
https://trac.sagemath.org/ticket/4102
https://trac.sagemath.org/ticket/4102
<ul>
<li><strong>attachment</strong>
set to <em>trac_4102-bessel_doctest_fixes2.patch</em>
</li>
</ul>
TicketeviatarbachThu, 20 Jun 2013 20:17:30 GMTstatus, description changed
https://trac.sagemath.org/ticket/4102#comment:79
https://trac.sagemath.org/ticket/4102#comment:79
<ul>
<li><strong>status</strong>
changed from <em>needs_work</em> to <em>needs_review</em>
</li>
<li><strong>description</strong>
modified (<a href="/ticket/4102?action=diff&version=79">diff</a>)
</li>
</ul>
<p>
New patch, adding a tolerance for the integral which is higher than the maximum error given by GSL.
</p>
TicketburcinThu, 20 Jun 2013 20:46:27 GMTstatus changed
https://trac.sagemath.org/ticket/4102#comment:80
https://trac.sagemath.org/ticket/4102#comment:80
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>positive_review</em>
</li>
</ul>
<p>
Thanks!
</p>
TicketjdemeyerWed, 31 Jul 2013 12:52:56 GMTstatus changed; resolution, merged set
https://trac.sagemath.org/ticket/4102#comment:81
https://trac.sagemath.org/ticket/4102#comment:81
<ul>
<li><strong>status</strong>
changed from <em>positive_review</em> to <em>closed</em>
</li>
<li><strong>resolution</strong>
set to <em>fixed</em>
</li>
<li><strong>merged</strong>
set to <em>sage-5.11.rc0</em>
</li>
</ul>
TicketeviatarbachWed, 07 Aug 2013 06:21:24 GMT
https://trac.sagemath.org/ticket/4102#comment:82
https://trac.sagemath.org/ticket/4102#comment:82
<p>
This is wrong:
</p>
<pre class="wiki">sage: var('nu z')
(nu, z)
sage: bessel_J(nu, z).diff(nu)
-1/2*bessel_J(nu + 1, z) + 1/2*bessel_J(nu - 1, z)
sage: bessel_J(nu, z).diff(z)
-1/2*bessel_J(nu + 1, z) + 1/2*bessel_J(nu - 1, z)
</pre>
TicketeviatarbachWed, 07 Aug 2013 06:38:34 GMTattachment set
https://trac.sagemath.org/ticket/4102
https://trac.sagemath.org/ticket/4102
<ul>
<li><strong>attachment</strong>
set to <em>trac4102_diff.patch</em>
</li>
</ul>
TicketeviatarbachWed, 07 Aug 2013 06:40:02 GMT
https://trac.sagemath.org/ticket/4102#comment:83
https://trac.sagemath.org/ticket/4102#comment:83
<p>
New patch fixes this issue. Can this be merged in 5.11?
</p>
TicketjdemeyerWed, 07 Aug 2013 07:44:07 GMT
https://trac.sagemath.org/ticket/4102#comment:84
https://trac.sagemath.org/ticket/4102#comment:84
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/4102#comment:83" title="Comment 83">eviatarbach</a>:
</p>
<blockquote class="citation">
<p>
New patch fixes this issue. Can this be merged in 5.11?
</p>
</blockquote>
<p>
No, you should make a follow-up ticket for this.
</p>
TicketeviatarbachWed, 07 Aug 2013 07:46:03 GMT
https://trac.sagemath.org/ticket/4102#comment:85
https://trac.sagemath.org/ticket/4102#comment:85
<p>
Oh okay, then can this ticket be removed from 5.11? I'm just worried about having mathematically incorrect answers in the release.
</p>
TicketjdemeyerWed, 07 Aug 2013 07:54:11 GMT
https://trac.sagemath.org/ticket/4102#comment:86
https://trac.sagemath.org/ticket/4102#comment:86
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/4102#comment:83" title="Comment 83">eviatarbach</a>:
</p>
<blockquote class="citation">
<p>
New patch fixes this issue. Can this be merged in 5.11?
</p>
</blockquote>
<p>
Sorry, I really meant: perhaps yes it can be in sage-5.11, but in any case there needs to be a follow-up ticket (make it milestone: sage-5.11 and priority: blocker) and the new patch needs to be reviewed.
</p>
TicketjdemeyerWed, 07 Aug 2013 07:58:47 GMT
https://trac.sagemath.org/ticket/4102#comment:87
https://trac.sagemath.org/ticket/4102#comment:87
<p>
Also, add a doctest for the <code>NotImplementedError</code> (like the tests from <a class="ticket" href="https://trac.sagemath.org/ticket/4102#comment:82" title="Comment 82">82</a>)
</p>
TicketeviatarbachWed, 07 Aug 2013 08:21:07 GMT
https://trac.sagemath.org/ticket/4102#comment:88
https://trac.sagemath.org/ticket/4102#comment:88
<p>
Okay, thank you. This is now <a class="closed ticket" href="https://trac.sagemath.org/ticket/15019" title="defect: Don't allow differentiation with respect to order in Bessel functions (closed: fixed)">#15019</a>.
</p>
Ticket