Sage: Ticket #11143: define symbolic functions for exponential integrals
https://trac.sagemath.org/ticket/11143
<p>
We're missing some conversions from Maxima. Like exponential integrals of various kinds.
</p>
<pre class="wiki">sage: f(x) = e^(-x) * log(x+1)
sage: uu = integral(f,x,0,oo)
sage: uu
x |--> e*expintegral_e(1, 1)
</pre><p>
See <a class="ext-link" href="http://ask.sagemath.org/question/488/calculating-integral"><span class="icon"></span>this ask.sagemath post</a> for some details.
</p>
<h2 id="Currentsymbolconversiontable">Current symbol conversion table</h2>
<p>
From <code>sage.symbolic.pynac.symbol_table['maxima']</code> as of Sage-4.7
</p>
<pre class="wiki">Maxima ---> Sage
%gamma ---> euler_gamma
%pi ---> pi
(1+sqrt(5))/2 ---> golden_ratio
acos ---> arccos
acosh ---> arccosh
acot ---> arccot
acoth ---> arccoth
acsc ---> arccsc
acsch ---> arccsch
asec ---> arcsec
asech ---> arcsech
asin ---> arcsin
asinh ---> arcsinh
atan ---> arctan
atan2 ---> arctan2
atanh ---> arctanh
binomial ---> binomial
brun ---> brun
catalan ---> catalan
ceiling ---> ceil
cos ---> cos
delta ---> dirac_delta
elliptic_e ---> elliptic_e
elliptic_ec ---> elliptic_ec
elliptic_eu ---> elliptic_eu
elliptic_f ---> elliptic_f
elliptic_kc ---> elliptic_kc
elliptic_pi ---> elliptic_pi
exp ---> exp
expintegral_e ---> En
factorial ---> factorial
gamma_incomplete ---> gamma
glaisher ---> glaisher
imagpart ---> imag_part
inf ---> +Infinity
infinity ---> Infinity
khinchin ---> khinchin
kron_delta ---> kronecker_delta
li[2] ---> dilog
log ---> log
log(2) ---> log2
mertens ---> mertens
minf ---> -Infinity
psi[0] ---> psi
realpart ---> real_part
signum ---> sgn
sin ---> sin
twinprime ---> twinprime
</pre><h1 id="Summaryofmissingconversions">Summary of missing conversions</h1>
<h2 id="SpecialfunctionsdefinedinMaxima">Special functions defined in Maxima</h2>
<p>
(<a class="ext-link" href="http://maxima.sourceforge.net/docs/manual/en/maxima_16.html#SEC56"><span class="icon"></span>http://maxima.sourceforge.net/docs/manual/en/maxima_16.html#SEC56</a>)
</p>
<pre class="wiki">bessel_j (index, expr) Bessel function, 1st kind
bessel_y (index, expr) Bessel function, 2nd kind
bessel_i (index, expr) Modified Bessel function, 1st kind
bessel_k (index, expr) Modified Bessel function, 2nd kind
</pre><ul><li>Notes: bessel_I, bessel_J, etc. are functions in Sage for numerical evaluation. There is also the <code>Bessel</code> class, but no conversions from Maxima's bessel_i etc. to Sage.
</li></ul><pre class="wiki">hankel_1 (v,z) Hankel function of the 1st kind
hankel_2 (v,z) Hankel function of the 2nd kind
struve_h (v,z) Struve H function
struve_l (v,z) Struve L function
</pre><ul><li>Notes: None of these functions are currently exposed at the top level in Sage. Evaluation is possible using mpmath.
</li></ul><pre class="wiki">assoc_legendre_p[v,u] (z) Legendre function of degree v and order u
assoc_legendre_q[v,u] (z) Legendre function, 2nd kind
</pre><ul><li>Notes: In Sage we have <code>legendre_P(n, x)</code> and <code>legendre_Q(n, x)</code> both described as Legendre functions. It's not clear to me how there are related to Maxima's versions since the number of arguments differs.
</li></ul><pre class="wiki">%f[p,q] ([], [], expr) Generalized Hypergeometric function
hypergeometric(l1, l2, z) Hypergeometric function
slommel
%m[u,k] (z) Whittaker function, 1st kind
%w[u,k] (z) Whittaker function, 2nd kind
</pre><ul><li>Notes: <code>hypergeometric(l1, l2, z)</code> needs a conversion to Sage's <code>hypergeometric_U</code>. The others can be evaluated using mpmath. <code>slommel</code> is presumably mpmath's <code>lommels1()</code> or <code>lommels2()</code> (or both?). This isn't well documented in Maxima.
</li></ul><pre class="wiki">expintegral_e (v,z) Exponential integral E
expintegral_e1 (z) Exponential integral E1
expintegral_ei (z) Exponential integral Ei
expintegral_li (z) Logarithmic integral Li
expintegral_si (z) Exponential integral Si
expintegral_ci (z) Exponential integral Ci
expintegral_shi (z) Exponential integral Shi
expintegral_chi (z) Exponential integral Chi
erfc (z) Complement of the erf function
</pre><ul><li>Notes: The exponential integral functions <code>expintegral_e1</code> and <code>expintegral_ei (z)</code> are called <code>exponential_integral_1</code> and <code>Ei</code> resp. in Sage. They both need conversions. The rest need <code>BuiltinFunction</code> classes defined for them with evaluation handled by mpmath and the symbol table conversion added. Also, <code>erfc</code> is called <code>error_fcn</code>, so also needs a conversion.
</li></ul><pre class="wiki">kelliptic (z) Complete elliptic integral of the first
kind (K)
parabolic_cylinder_d (v,z) Parabolic cylinder D function
</pre><ul><li>Notes: <code>kelliptic(z)</code> needs a conversion to <code>elliptic_kc</code> in Sage and <code>parabolic_cylinder_d (v,z)</code> does not seem to be exposed at top level. It can be evaluated by mpmath.
</li></ul><hr />
<p>
Apply to the Sage library:
</p>
<ol><li><a class="attachment" href="https://trac.sagemath.org/attachment/ticket/11143/trac_11143-v2.5-rebased.4.patch" title="Attachment 'trac_11143-v2.5-rebased.4.patch' in Ticket #11143">trac_11143-v2.5-rebased.4.patch</a><a class="trac-rawlink" href="https://trac.sagemath.org/raw-attachment/ticket/11143/trac_11143-v2.5-rebased.4.patch" title="Download"></a>
</li><li><a class="attachment" href="https://trac.sagemath.org/attachment/ticket/11143/trac-11143-ref.2.patch" title="Attachment 'trac-11143-ref.2.patch' in Ticket #11143">trac-11143-ref.2.patch</a><a class="trac-rawlink" href="https://trac.sagemath.org/raw-attachment/ticket/11143/trac-11143-ref.2.patch" title="Download"></a>
</li><li><a class="attachment" href="https://trac.sagemath.org/attachment/ticket/11143/trac_11143-pynac-serials.patch" title="Attachment 'trac_11143-pynac-serials.patch' in Ticket #11143">trac_11143-pynac-serials.patch</a><a class="trac-rawlink" href="https://trac.sagemath.org/raw-attachment/ticket/11143/trac_11143-pynac-serials.patch" title="Download"></a>
</li></ol>en-usSagehttps://trac.sagemath.org/chrome/site/logo_sagemath_trac.png
https://trac.sagemath.org/ticket/11143
Trac 1.1.6benjaminfjonesWed, 20 Apr 2011 20:13:19 GMT
https://trac.sagemath.org/ticket/11143#comment:1
https://trac.sagemath.org/ticket/11143#comment:1
<p>
As far as I can tell, the general <code>exponential_e</code> function isn't available directly in Sage or in PARI (which is used to evaluate the <code>exponential_integral_1</code> function in Sage).
</p>
<p>
Also, it's possible to get maxima to rewrite the exponential integrals in terms of gamma functions like so:
</p>
<div class="wiki-code"><div class="code"><pre>sage<span class="p">:</span> maxima<span class="o">.</span>eval<span class="p">(</span><span class="s">'expintrep:gamma_incomplete'</span><span class="p">)</span>
<span class="s">'gamma_incomplete'</span>
sage<span class="p">:</span> maxima<span class="o">.</span>integrate<span class="p">(</span>exp<span class="p">(</span><span class="o">-</span>x<span class="p">)</span><span class="o">*</span>log<span class="p">(</span>x<span class="o">+</span><span class="mi">1</span><span class="p">),</span> x<span class="p">,</span> <span class="mi">0</span><span class="p">,</span> oo<span class="p">)</span>
<span class="o">%</span>e<span class="o">*</span>gamma_incomplete<span class="p">(</span><span class="mi">0</span><span class="p">,</span><span class="mi">1</span><span class="p">)</span>
sage<span class="p">:</span> N<span class="p">(</span>e<span class="o">*</span>gamma<span class="p">(</span><span class="mi">0</span><span class="p">,</span><span class="mi">1</span><span class="p">),</span> digits<span class="o">=</span><span class="mi">18</span><span class="p">)</span>
<span class="mf">0.596347362323194074</span>
</pre></div></div><p>
But as you see, <code>gamma_incomplete</code> isn't defined in Sage either, but the table <code>sage.symbolic.pynac.symbol_table['maxima']</code> lists the Sage equivalent <code>gamma</code>. Anyway, it should be possible to have the maxima interface (with the help of maxima itself) rewrite any exponential integral that Sage doesn't have in terms of gamma functions.
</p>
<p>
By the way, the owner on the ticket is @burcin, does that mean they are working on it currently?
</p>
TicketbenjaminfjonesWed, 20 Apr 2011 20:13:41 GMTcc set
https://trac.sagemath.org/ticket/11143#comment:2
https://trac.sagemath.org/ticket/11143#comment:2
<ul>
<li><strong>cc</strong>
<em>benjaminfjones</em> added
</li>
</ul>
TicketkcrismanWed, 20 Apr 2011 20:42:29 GMT
https://trac.sagemath.org/ticket/11143#comment:3
https://trac.sagemath.org/ticket/11143#comment:3
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/11143#comment:1" title="Comment 1">benjaminfjones</a>:
</p>
<blockquote class="citation">
<p>
As far as I can tell, the general <code>exponential_e</code> function isn't available directly in Sage or in PARI (which is used to evaluate the <code>exponential_integral_1</code> function in Sage).
</p>
</blockquote>
<p>
That's unfortunate. However, <a class="ext-link" href="http://mpmath.googlecode.com/svn/trunk/doc/build/functions/expintegrals.html#mpmath.expint"><span class="icon"></span>mpmath seems to have it</a>. So we could create a symbolic version and have the <code>_eval_</code> method call mpmath, which we seem to be moving to.
</p>
<blockquote class="citation">
<p>
Also, it's possible to get maxima to rewrite the exponential integrals in terms of gamma functions like so:
</p>
<div class="wiki-code"><div class="code"><pre>sage<span class="p">:</span> maxima<span class="o">.</span>eval<span class="p">(</span><span class="s">'expintrep:gamma_incomplete'</span><span class="p">)</span>
<span class="s">'gamma_incomplete'</span>
sage<span class="p">:</span> maxima<span class="o">.</span>integrate<span class="p">(</span>exp<span class="p">(</span><span class="o">-</span>x<span class="p">)</span><span class="o">*</span>log<span class="p">(</span>x<span class="o">+</span><span class="mi">1</span><span class="p">),</span> x<span class="p">,</span> <span class="mi">0</span><span class="p">,</span> oo<span class="p">)</span>
<span class="o">%</span>e<span class="o">*</span>gamma_incomplete<span class="p">(</span><span class="mi">0</span><span class="p">,</span><span class="mi">1</span><span class="p">)</span>
sage<span class="p">:</span> N<span class="p">(</span>e<span class="o">*</span>gamma<span class="p">(</span><span class="mi">0</span><span class="p">,</span><span class="mi">1</span><span class="p">),</span> digits<span class="o">=</span><span class="mi">18</span><span class="p">)</span>
<span class="mf">0.596347362323194074</span>
</pre></div></div></blockquote>
<p>
Interesting.
</p>
<blockquote class="citation">
<p>
But as you see, <code>gamma_incomplete</code> isn't defined in Sage either, but the table <code>sage.symbolic.pynac.symbol_table['maxima']</code> lists the Sage equivalent <code>gamma</code>.
</p>
</blockquote>
<p>
That should be ok; the whole point of the table is to convert into the Sage equivalent.
</p>
<blockquote class="citation">
<p>
By the way, the owner on the ticket is @burcin, does that mean they are working on it currently?
</p>
</blockquote>
<p>
No, that is an automatic thing that happens. It is possible to be designated an 'owner' of a ticket in a given component, which basically means you automatically get updates. If you want to 'own' it, please do! We really have plenty of special functions in Sage, but they are not always well exposed at the top level.
</p>
<p>
Incidentally, once you comment on a ticket, I believe the default is to copy you in on all replies. So you didn't have to cc: yourself specially :)
</p>
TicketburcinThu, 21 Apr 2011 08:10:47 GMT
https://trac.sagemath.org/ticket/11143#comment:4
https://trac.sagemath.org/ticket/11143#comment:4
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/11143#comment:1" title="Comment 1">benjaminfjones</a>:
</p>
<blockquote class="citation">
<p>
But as you see, <code>gamma_incomplete</code> isn't defined in Sage either, but the table <code>sage.symbolic.pynac.symbol_table['maxima']</code> lists the Sage equivalent <code>gamma</code>. Anyway, it should be possible to have the maxima interface (with the help of maxima itself) rewrite any exponential integral that Sage doesn't have in terms of gamma functions.
</p>
</blockquote>
<p>
Incomplete gamma is defined in Sage. You can access it directly though <code>incomplete_gamma()</code> or <code>gamma_inc()</code>. The top level function <code>gamma()</code> behaves like incomplete gamma if you give it two arguments. IIRC, this is similar to maple.
</p>
<blockquote class="citation">
<p>
By the way, the owner on the ticket is @burcin, does that mean they are working on it currently?
</p>
</blockquote>
<p>
I am not working on it. The ticket status <code>assigned</code> is supposed to indicate that the owner is working on the problem, but we don't use that much either.
</p>
TicketburcinWed, 25 May 2011 19:15:01 GMT
https://trac.sagemath.org/ticket/11143#comment:5
https://trac.sagemath.org/ticket/11143#comment:5
<p>
I guess the point of this ticket is to define symbolic function in Sage to represent exponential integrals, etc. The symbolic function class handles adding stuff to the conversion table automatically.
</p>
<p>
Can we replace this ticket with several beginner tickets? One for each function we are missing.
</p>
TicketkcrismanWed, 01 Jun 2011 03:09:58 GMT
https://trac.sagemath.org/ticket/11143#comment:6
https://trac.sagemath.org/ticket/11143#comment:6
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/11143#comment:5" title="Comment 5">burcin</a>:
</p>
<blockquote class="citation">
<p>
I guess the point of this ticket is to define symbolic function in Sage to represent exponential integrals, etc. The symbolic function class handles adding stuff to the conversion table automatically.
</p>
<p>
Can we replace this ticket with several beginner tickets? One for each function we are missing.
</p>
</blockquote>
<p>
Well, that would be nice. But we could also presumably do it directly, if that would solve this problem for now. Well, either is fine as long as it were to happen. If you do split this, be sure to give a good template (I mean a link to the template, not write it yourself).
</p>
TicketbenjaminfjonesWed, 08 Jun 2011 20:27:05 GMT
https://trac.sagemath.org/ticket/11143#comment:7
https://trac.sagemath.org/ticket/11143#comment:7
<p>
I'm attempting to write a template for the <code>expintegral_e</code> function (denoted E_n(z) in A&S). As I'm looking through the code, I see several models used for the functions and classes in <code>sage/functions/special.py</code> and <code>sage/functions/transcendental.py</code>
</p>
<ul><li>Functions like <code>Function_exp_integral</code> (also called <code>Ei</code>) are defined as classes that inherit from <code>BuiltInFunction</code> and call the mpmath implementation when evaluated. The function <code>DickmanRho</code> also does this and includes other nice methods for approximating values and power series.
</li><li>Functions like <code>EllipticE</code> inherit from <code>MaximaFunction</code> which handles evaluation, etc. through Maxima. It seems there is an advantage to the mpmath implementation because presumably the interface is faster and the precision is arbitrary (whereas Maxima is limited to 53 bits).
</li><li>Functions like <code>Li</code> and <code>error_fcn</code> are simply wrapper functions that try to evaluate the input symbolically or numerically depending on context.
</li><li>In <code>sage/functions/trig.py</code> there is a mixture of classes that derive from <code>GinacFunction</code> (and include information in their <code>__init__</code> methods about conversions to other systems like Maxima or Mathematica) and also functions that derive from <code>BuiltinFunction</code>. It's not clear to me why some functions are Ginac and some are Builtin.
</li></ul><p>
Questions:
</p>
<ul><li>For the purposes of this ticket, what is recommended? @kcrisman 's comment leads me to believe that inheriting from the <code>BuiltinFunction</code> class and using <code>mpmath</code> for evaluation is preferable.
</li><li>Where should the various exponential integral special functions that we are missing go? <code>sage/functions/special.py</code>, <code>sage/functions/transcendental.py</code>, or somewhere else?
</li></ul>
TicketkcrismanWed, 08 Jun 2011 20:45:13 GMT
https://trac.sagemath.org/ticket/11143#comment:8
https://trac.sagemath.org/ticket/11143#comment:8
<p>
Those are good questions.
</p>
<p>
I think the most important thing is to make sure that whatever is implemented has
</p>
<ul><li>good numerical evaluation (perhaps via mpmath)
</li><li>translates back and forth to Maxima properly (for integration and limits)
</li></ul><p>
My sense is that BuiltinFunction would be best. GinacFunction probably is only good for things that in fact evaluate in Ginac. This explains trig.py. <a class="ext-link" href="http://www.ginac.de/tutorial/Built_002din-functions.html|This"><span class="icon"></span>Ginac page</a> shows that the ones which are GinacFunctions are exactly the ones which Ginac in fact has. I don't think it has most of these other functions.
</p>
<p>
As for MaximaFunction, it seems to inherit from BuiltinFunction and lives in the special functions file. This dates from the days when Sage had very few options for symbolic stuff and evaluation, and so it just does a few extra things. If we moved to mpmath for a given function, we would probably use BuiltinFunction and then add evaluation options for Maxima and add to the conversion dictionary as needed.
</p>
<p>
In fact, it wouldn't be a bad idea to have two different eval procedures if possible...
</p>
<hr />
<p>
As for where such things go, probably it would make sense to separate a lot of these special functions out into a separate file. The distinction between transcendental and special is not totally obvious, for instance :)
</p>
<hr />
<p>
By the way, we certainly want fewer of the wrapper functions! But that will take a lot of tedious work.
</p>
TicketkcrismanWed, 08 Jun 2011 20:46:40 GMT
https://trac.sagemath.org/ticket/11143#comment:9
https://trac.sagemath.org/ticket/11143#comment:9
<p>
By the way, adding this will really be a great help. Sage has so many of the things almost anybody needs, but if you have to use mpmath or GSL or R or something else directly, it sort of makes Sage a moot point. The idea is having a one-stop shop.
</p>
TicketbenjaminfjonesSun, 12 Jun 2011 07:07:19 GMT
https://trac.sagemath.org/ticket/11143#comment:10
https://trac.sagemath.org/ticket/11143#comment:10
<p>
I've uploaded a first shot at a template for the functions we want to add in this ticket. The patch exposes the general complex exponential integral function <code>En</code> also called <code>Function_exp_integral_En</code> by adding a class to <code>sage/functions/special.py</code> (I can change where it goes later on if needed / desired). Numerical evaluation is handled by mpmath and symbolics are handled by Sage (e.g. the derivative) and Maxima (e.g. the antiderivative).
</p>
<p>
One of the docstring examples shows that the integral of <code>e^(-x) * log(x+1)</code> from the ticket description is now evaluated properly.
</p>
<p>
Any comments or suggestions?
</p>
TicketbenjaminfjonesMon, 13 Jun 2011 02:10:22 GMTkeywords, description changed
https://trac.sagemath.org/ticket/11143#comment:11
https://trac.sagemath.org/ticket/11143#comment:11
<ul>
<li><strong>keywords</strong>
<em>special</em> <em>function</em> <em>maxima</em> added
</li>
<li><strong>description</strong>
modified (<a href="/ticket/11143?action=diff&version=11">diff</a>)
</li>
</ul>
TicketburcinMon, 13 Jun 2011 20:20:19 GMTsummary changed; reviewer, milestone, author set
https://trac.sagemath.org/ticket/11143#comment:12
https://trac.sagemath.org/ticket/11143#comment:12
<ul>
<li><strong>reviewer</strong>
set to <em>Burcin Erocal</em>
</li>
<li><strong>milestone</strong>
set to <em>sage-4.7.1</em>
</li>
<li><strong>author</strong>
set to <em>Benjamin Jones</em>
</li>
<li><strong>summary</strong>
changed from <em>Add various Maxima special functions to symbol table</em> to <em>define symbolic functions for exponential integrals</em>
</li>
</ul>
<p>
The patch looks great. Thanks for the template. A few suggestions:
</p>
<ul><li>The function name should be more explicit. I suggest <code>exp_integral_e</code>.
</li><li>In the top level name space <code>En</code> can be an alias for this function (though I'd prefer not to take up a two letter name), but we should have the long name available. It is easier to find all these functions by <code>exp_integral<tab></code> than <code>E<tab></code>.
</li><li>See <a class="ext-link" href="http://hg.sagemath.org/sage-main/file/tip/sage/functions/other.py#l680"><span class="icon"></span>_eval_ method of sage.functions.other.Function_gamma_inc</a> for an example of how to find a common parent for the arguments
</li><li>The call to mpmath does not require the prec parameter any more. If you pass a Sage element to mpmath it handles the precision correctly. You can delete the code for this in <code>_evalf_()</code>.
</li><li>You should remove the <code>__call__()</code> method altogether. The only purpose of that is to display the deprecation notice. Since you are implementing a new function here, there is nothing being deprecated.
</li><li>In <code>_derivative_()</code> the call to this function should be <code>exp_integral_e(n-1, z)</code>, assuming you change the function name accordingly.
</li></ul><p>
I changed the ticket description to limit this to implementing symbolic functions for exponential integrals. We can use <a class="wiki" href="https://trac.sagemath.org/wiki/symbolics/functions">the wiki page</a> for a general overview of the progress on symbolic functions.
</p>
TicketbenjaminfjonesWed, 15 Jun 2011 00:44:53 GMT
https://trac.sagemath.org/ticket/11143#comment:13
https://trac.sagemath.org/ticket/11143#comment:13
<p>
Thanks for the feedback, Burcin! I feel like I'm developing an understanding for how symbolic functions are handled in Sage now.
</p>
<p>
To your suggestions:
</p>
<ul><li>I agree, the changed the name of the class to <code>Function_exp_integral_e</code> and the global function name to <code>exp_integral_e</code>. I think it would make sense as part of this ticket to add an alias of <code>exp_integral_1</code> for the existing <code>exponential_integral_1</code> to be consistent.
</li><li>Good point, I didn't think of that.
</li><li>The function now correctly coerces the two arguments to the same parent. I also added automatic evaluation of some special cases (n=0 or z=0) as in the <code>gamma_inc</code> function.
</li><li>I played around with removing the prec argument, but didn't get the results I expected. I found that passing the parent explicitly works. The common parent is determined in _eval_ (as in the <code>gamma_inc</code> function).
</li><li>Done.
</li><li>Done.
</li></ul><p>
Let me know what you think. Once we've agreed on a good template for this one function, I will implement the rest of the exponential integral functions that are now listed on the wiki and upload to this ticket.
</p>
TicketburcinWed, 15 Jun 2011 03:59:16 GMT
https://trac.sagemath.org/ticket/11143#comment:14
https://trac.sagemath.org/ticket/11143#comment:14
<p>
Perfect! I can only nitpick about documentation. :)
</p>
<ul><li>lines should be < 80 characters long. This helps when viewing help in a terminal.
</li><li>I don't know how testing for 0 in <code>_eval_</code> effects performance. This is a hard problem. See the <code>_eval_</code> methods in <code>sage/functions/generalized.py</code> for a workaround if this is too slow.
</li></ul><p>
You're right, we should add an alias <code>exp_integral_1</code>.
</p>
<p>
Thanks for working on this.
</p>
TicketbenjaminfjonesThu, 16 Jun 2011 20:30:10 GMTcc deleted
https://trac.sagemath.org/ticket/11143#comment:15
https://trac.sagemath.org/ticket/11143#comment:15
<ul>
<li><strong>cc</strong>
<em>benjaminfjones</em> removed
</li>
</ul>
<p>
The tests similar to <code>if z == 0</code> in <code>_eval_</code> do make a big difference. I guess this is well known, but I didn't realize how big the speed difference is.
</p>
<p>
I made a little table below of some timings. In the first table , <code>_eval_</code> includes tests <code>if z == 0 and n > 1</code> and <code>if n == 0</code>. In the second table, there are no such if statements (so the special cases are not implemented). In the third table, the special cases are implementes as in <code>sage/functions/generalized.py</code> where an approximation of <code>z</code> (or <code>n</code>) is produced and checked instead of the symbol.
</p>
<div class="wiki-code"><div class="code"><pre>with <span class="s">``if z == 0``</span>
============================================= ========
Test Time
============================================= ========
sage: timeit("f = exp_integral_e(n,z)") 1.44 ms
sage: timeit("f = exp_integral_e(n,0)") 929 µs
sage: timeit("f = exp_integral_e(0,z)") 1.41 ms
sage: timeit("f = exp_integral_e(1.0,1.0)") 158 µs
============================================= ========
without <span class="s">``if z == 0``</span>
============================================= ======
Test Time
============================================= ======
sage: timeit("f = exp_integral_e(n,z)") 541 µs
sage: timeit("f = exp_integral_e(n,0)") 300 µs
sage: timeit("f = exp_integral_e(0,z)") 299 µs
sage: timeit("f = exp_integral_e(1.0,1.0)") 161 µs
============================================= ======
with:
<span class="p">..</span> <span class="ow">code-block</span><span class="p">::</span> python
try:
approx_z = ComplexIntervalField()(z)
# if z is zero and n > 1
if bool(approx_z.imag() == 0) and bool(approx_z.real() == 0):
if n > 1:
return 1/(n-1)
except: # z is symbolic
pass
# if n is zero
try:
approx_n = ComplexIntervalField()(n)
if bool(approx_n.imag() == 0) and bool(approx_n.real() == 0):
return exp(-z)/z
except: # n is symbolic
pass
============================================= ======
Test Time
============================================= ======
sage: timeit("f = exp_integral_e(n,z)") 570 µs
sage: timeit("f = exp_integral_e(n,0)") 576 µs
sage: timeit("f = exp_integral_e(0,z)") 1.05 ms
sage: timeit("f = exp_integral_e(1.0,1.0)") 160 µs
============================================= ======
</pre></div></div><p>
Timings in tables 2 and 3 are close except in the case where <code></code>exp(-z)/z<code></code> is
returned, whereas table 1 is anywhere from a factor of 3 to 5 slower than in table 2 when a symbolic argument is passed. Anyway, I thought I'd include the above for other beginners such as myself.
</p>
<hr />
<p>
Another thing I discovered is that these two special cases that I was
implementing are known to Maxima:
</p>
<pre class="wiki">sage: f = exp_integral_e(0,x)
sage: f
exp_integral_e(0,x)
sage: f.simplify()
e^(-x)/x
sage: nn = var('nn')
sage: assume(nn > 1)
sage: f = exp_integral_e(nn, 0)
sage: f
exp_integral_e(nn, 0)
sage: f.simplify()
1/(nn - 1)
</pre><p>
So I think in the interest of speedy evaluation it's best to leave the special
cases out, but point out in the documentation that Maxima knows about them.
</p>
<p>
I've uploaded a new patch. I'll start implementing the other exponential integrals using this as a template.
</p>
TicketburcinThu, 16 Jun 2011 22:41:05 GMT
https://trac.sagemath.org/ticket/11143#comment:16
https://trac.sagemath.org/ticket/11143#comment:16
<p>
The timings are really instructive, we should link to them from <a class="wiki" href="https://trac.sagemath.org/wiki/symbolics/functions">wiki page</a>. Thank you for this careful study.
</p>
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/11143#comment:15" title="Comment 15">benjaminfjones</a>:
</p>
<blockquote class="citation">
<p>
So I think in the interest of speedy evaluation it's best to leave the special
cases out, but point out in the documentation that Maxima knows about them.
</p>
</blockquote>
<p>
I think your timings show that using the CIF approximation is not such a big penalty. Note that your timings also reflect the construction of the result and not just including that change. It is better if Sage can do the evaluation automatically without having to pass through a <code>simplify()</code> call. I'd like them in, with the approximation approach.
</p>
<p>
Since this approximation is being called so often, we should make it a method of symbolic expressions. I opened a new ticket for this: <a class="closed ticket" href="https://trac.sagemath.org/ticket/11513" title="enhancement: add is_trivial_zero() method to symbolic expressions (closed: fixed)">#11513</a>. This ticket should depend on that.
</p>
<p>
I will provide a preliminary patch for <a class="closed ticket" href="https://trac.sagemath.org/ticket/11513" title="enhancement: add is_trivial_zero() method to symbolic expressions (closed: fixed)">#11513</a> soon.
</p>
TicketburcinFri, 17 Jun 2011 00:22:30 GMT
https://trac.sagemath.org/ticket/11143#comment:17
https://trac.sagemath.org/ticket/11143#comment:17
<p>
I attached a very simple patch to <a class="closed ticket" href="https://trac.sagemath.org/ticket/11513" title="enhancement: add is_trivial_zero() method to symbolic expressions (closed: fixed)">#11513</a>. Now we can write the check for zero as:
</p>
<pre class="wiki">def is_zero(z):
if isinstance(z, Expression):
return z._is_numerically_zero()
else:
return not z
</pre><p>
It would be nice if we could simplify this further, but I need to go and do other things now. :)
</p>
TicketbenjaminfjonesMon, 20 Jun 2011 18:24:21 GMT
https://trac.sagemath.org/ticket/11143#comment:18
https://trac.sagemath.org/ticket/11143#comment:18
<p>
The patch now depends on <a class="closed ticket" href="https://trac.sagemath.org/ticket/11513" title="enhancement: add is_trivial_zero() method to symbolic expressions (closed: fixed)">#11513</a>
</p>
<p>
Here are new timings for the <code></code>_eval_<code></code> method with <code></code>_is_numerically_zero()<code></code>:
</p>
<div class="wiki-code"><div class="code"><pre><span class="p">..</span> <span class="ow">code-block</span><span class="p">::</span> python
# special case: <span class="ge">*quickly*</span> test if (z == 0 and n > 1)
if isinstance(z, Expression):
if z._is_numerically_zero():
z_zero = True # for later
if n > 1:
return 1/(n-1)
else:
if not z:
z_zero = True
if n > 1:
return 1/(n-1)
====================================================== =======
Test Time
====================================================== =======
sage: timeit("f = exp_integral_e(n,z)") 535 µs
sage: timeit("f = exp_integral_e(n,0)") 482 µs
sage: assume(n > 1); timeit("f = exp_integral_e(n,0)") 3.56 ms
sage: timeit("f = exp_integral_e(0,z)") 968 µs
sage: timeit("f = exp_integral_e(1.0,1.0)") 160 µs
====================================================== =======
</pre></div></div><p>
I realized that in row 2 of the previous timings I neglected to assume n > 1 so those timings aren't giving much information since the expression is left unevaluated like in row 1. The new row 3 includes that assumption so that the simplified result <code></code>1/(n-1)<code></code> is created and returned.
</p>
<p>
I'll update the timings above and move these tables to the wiki.
</p>
TicketbenjaminfjonesMon, 20 Jun 2011 18:27:24 GMTattachment set
https://trac.sagemath.org/ticket/11143
https://trac.sagemath.org/ticket/11143
<ul>
<li><strong>attachment</strong>
set to <em>trac_11143_En.patch</em>
</li>
</ul>
<p>
added the symbolic function <code>exp_integral_e</code>
</p>
TicketbenjaminfjonesSat, 02 Jul 2011 20:59:53 GMTowner changed
https://trac.sagemath.org/ticket/11143#comment:19
https://trac.sagemath.org/ticket/11143#comment:19
<ul>
<li><strong>owner</strong>
changed from <em>burcin</em> to <em>benjaminfjones</em>
</li>
</ul>
<p>
In the patch, I'm added a function to <code>sage/functions/special.py</code>. But with the six new functions, this is going to be *a lot* of code in the one file.
</p>
<p>
I was thinking of moving the six new functions to a new file <code>sage/functions/exp_integral.py</code>. Any thoughts? If that seems like a good idea, does it also make sense to move the exp integrals that already exist in Sage to the same place (e.g. <code>exponential_integral_1</code> lives now in <code>sage/functions/transcendental.py</code>.
</p>
TicketkcrismanSun, 03 Jul 2011 03:18:24 GMT
https://trac.sagemath.org/ticket/11143#comment:20
https://trac.sagemath.org/ticket/11143#comment:20
<blockquote class="citation">
<p>
I was thinking of moving the six new functions to a new file <code>sage/functions/exp_integral.py</code>. Any thoughts? If that seems like a good idea, does it also make sense to move the exp integrals that already exist in Sage to the same place (e.g. <code>exponential_integral_1</code> lives now in <code>sage/functions/transcendental.py</code>.
</p>
</blockquote>
<p>
Yes, absolutely. The functions/ folder needs to be reorganized, though obviously this is lower priority. Make sure that it still shows up in the reference manual, that all imports work fine, etc. But these functions are all supposed to be accessed through the top level namespace anyway, so this is a great idea to make it easier to organize.
</p>
TicketbenjaminfjonesTue, 23 Aug 2011 03:25:23 GMT
https://trac.sagemath.org/ticket/11143#comment:21
https://trac.sagemath.org/ticket/11143#comment:21
<p>
I've uploaded a new partial patch for the ticket. I wanted to post this now before I finish the patch so people can comment on the consolidation of exponential functions in the new file <code>sage/functions/exp_integral.py</code> and/or anything else.
</p>
<p>
If the basic organisation looks good, I'll finish up adding the remaining exponential integrals and upload a new patch.
</p>
TicketkcrismanTue, 23 Aug 2011 16:58:22 GMTreviewer changed; dependencies set
https://trac.sagemath.org/ticket/11143#comment:22
https://trac.sagemath.org/ticket/11143#comment:22
<ul>
<li><strong>reviewer</strong>
changed from <em>Burcin Erocal</em> to <em>Burcin Erocal, Karl-Dieter Crisman</em>
</li>
<li><strong>dependencies</strong>
set to <em>#11513</em>
</li>
</ul>
<p>
A few comment:
</p>
<ul><li>This will conflict (slightly) with <a class="closed ticket" href="https://trac.sagemath.org/ticket/11043" title="defect: Lazily import plot. (closed: invalid)">#11043</a>, I think. You can help their cause by doing
<pre class="wiki">from sage.plot.all import plot
</pre>I believe. The point is making sure we don't import numpy and other things like that on startup. It's possible that some of the other imports will have this problem, but hopefully not (?).
</li><li>I don't really understand coercion, so I'm reluctant to comment on the coercion stuff in <code>_eval_</code>, though I'd be glad if you explained that (I don't recall seeing it in these types of functions before).
</li><li>This seems to depend on <a class="closed ticket" href="https://trac.sagemath.org/ticket/11513" title="enhancement: add is_trivial_zero() method to symbolic expressions (closed: fixed)">#11513</a> still, so I'm adding that. But that still does not have positive review. Just pointing it out.
</li><li>Line 260: <code> raise NotImplementedError("The derivative of is only implemented for n = 1, 2, 3, ...") </code> seems to be missing something.
</li></ul><p>
On a cursory reading, this looks really nice. Certainly you should go ahead with the full reorganization, that will help a lot.
</p>
TicketbenjaminfjonesThu, 25 Aug 2011 18:04:34 GMTkeywords changed
https://trac.sagemath.org/ticket/11143#comment:23
https://trac.sagemath.org/ticket/11143#comment:23
<ul>
<li><strong>keywords</strong>
<em>sd32</em> added
</li>
</ul>
TicketbenjaminfjonesThu, 22 Sep 2011 01:06:23 GMT
https://trac.sagemath.org/ticket/11143#comment:24
https://trac.sagemath.org/ticket/11143#comment:24
<p>
Trying to finish up the patch, I've run into a problem evaluating any of my new functions at python floats. For example, apply the patch and try:
</p>
<pre class="wiki">sage: exp_integral_e1(float(1))
ERROR: An unexpected error occurred while tokenizing input
The following traceback may be corrupted or invalid
The error message is: ('EOF in multi-line statement', (690, 0))
---------------------------------------------------------------------------
AttributeError Traceback (most recent call last)
/Users/jonesbe/sage/sage-4.7.2.alpha2/devel/sage-test/sage/<ipython console> in <module>()
/Users/jonesbe/sage/latest/local/lib/python2.6/site-packages/sage/symbolic/function.so in sage.symbolic.function.Function.__call__ (sage/symbolic/function.cpp:4599)()
/Users/jonesbe/sage/latest/local/lib/python2.6/site-packages/sage/functions/exp_integral.pyc in _eval_(self, z)
335 """
336 if not isinstance(z, Expression) and is_inexact(z):
--> 337 return self._evalf_(z, parent(z))
338
339 return None # leaves the expression unevaluated
/Users/jonesbe/sage/latest/local/lib/python2.6/site-packages/sage/functions/exp_integral.pyc in _evalf_(self, z, parent)
350 """
351 import mpmath
--> 352 return mpmath_utils.call(mpmath.e1, z, parent=parent)
353
354 def _derivative_(self, z, diff_param=None):
/Users/jonesbe/sage/latest/local/lib/python2.6/site-packages/sage/libs/mpmath/utils.so in sage.libs.mpmath.utils.call (sage/libs/mpmath/utils.c:5277)()
AttributeError: type object 'float' has no attribute 'prec'
</pre><p>
You also get the error if you try to plot any of the exponential integral functions as they are written unless you wrap the input with <code>RDF</code> or something similar.
</p>
<p>
The error is being raised inside the <code>call</code> function in <code>sage/libs/mpmath/util.pyx</code>. I've looked through that code and thought about what would happen if the <code>prec</code> option is not specified (as in my code) and the parent is <code>None</code> (as when a python float is passed), but I can't figure out why it doesn't work to pass a float.
</p>
<p>
On the other hand, changing the lines in the <code>_evalf</code> method
</p>
<pre class="wiki">import mpmath
return mpmath_utils.call(mpmath.e1, z, parent=parent)
</pre><p>
to
</p>
<pre class="wiki">import mpmath
if isinstance(parent, Parent) and hasattr(parent, 'prec'):
prec = parent.prec()
else:
prec = 53
return mpmath_utils.call(mpmath.si, z, prec=prec)
</pre><p>
fixes the error.
</p>
<p>
What do people think? Is this a bug in the <code>call</code> function (which claims it will accept any type that mpmath handles natively like python floats) or is there something wrong with my code?
</p>
TicketburcinThu, 22 Sep 2011 09:33:22 GMT
https://trac.sagemath.org/ticket/11143#comment:25
https://trac.sagemath.org/ticket/11143#comment:25
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/11143#comment:24" title="Comment 24">benjaminfjones</a>:
</p>
<blockquote class="citation">
<p>
What do people think? Is this a bug in the <code>call</code> function (which claims it will accept any type that mpmath handles natively like python floats) or is there something wrong with my code?
</p>
</blockquote>
<p>
It would be better to fix the <code>mpmath_call()</code> function. This is called from many places and duplicating the code to check if <code>parent</code> has a <code>prec()</code> method everywhere is error prone.
</p>
<p>
Thanks for your work on this so far. I will try to come up with an acceptable implementation for <a class="closed ticket" href="https://trac.sagemath.org/ticket/11513" title="enhancement: add is_trivial_zero() method to symbolic expressions (closed: fixed)">#11513</a> next week. I hope it doesn't hold this up for long.
</p>
TicketbenjaminfjonesFri, 30 Sep 2011 19:11:22 GMT
https://trac.sagemath.org/ticket/11143#comment:26
https://trac.sagemath.org/ticket/11143#comment:26
<p>
Ok, I've created a new ticket <a class="closed ticket" href="https://trac.sagemath.org/ticket/11885" title="defect: call function in sage.libs.mpmath.utils doesn't handle parent=parent(float) (closed: fixed)">#11885</a> to fix the issue with <code>mpmath.utils.call</code> and uploaded a patch there. I'll upload the finished patch for <a class="closed ticket" href="https://trac.sagemath.org/ticket/11143" title="defect: define symbolic functions for exponential integrals (closed: fixed)">#11143</a> that depends on it later this afternoon.
</p>
TicketbenjaminfjonesThu, 06 Oct 2011 04:02:53 GMTdescription changed
https://trac.sagemath.org/ticket/11143#comment:27
https://trac.sagemath.org/ticket/11143#comment:27
<ul>
<li><strong>description</strong>
modified (<a href="/ticket/11143?action=diff&version=27">diff</a>)
</li>
</ul>
TicketbenjaminfjonesThu, 06 Oct 2011 04:12:24 GMTstatus changed
https://trac.sagemath.org/ticket/11143#comment:28
https://trac.sagemath.org/ticket/11143#comment:28
<ul>
<li><strong>status</strong>
changed from <em>new</em> to <em>needs_review</em>
</li>
</ul>
<p>
The patch just uploaded should be feature complete. I've checked the documentation, checked that the doctests pass, and checked that <code></code>make ptestlong<code></code> completes without errors on Mac OS X 10.6.8 and also debian linux squeeze. The patch is based on sage-4.7.2.alpha3.
</p>
TicketbenjaminfjonesThu, 06 Oct 2011 15:39:27 GMTattachment set
https://trac.sagemath.org/ticket/11143
https://trac.sagemath.org/ticket/11143
<ul>
<li><strong>attachment</strong>
set to <em>trac_11143.patch</em>
</li>
</ul>
<p>
adds sage/functions/exp_integral.py
</p>
TicketbenjaminfjonesThu, 06 Oct 2011 15:42:56 GMT
https://trac.sagemath.org/ticket/11143#comment:29
https://trac.sagemath.org/ticket/11143#comment:29
<p>
There were a few doctests failing in sage/misc/sagedoc.py that I missed. The patch just uploaded now *really* doesn't break anything according to <code>make ptestlong</code>.
</p>
<p>
There are some strange doctests in sagedoc.py, especially the recursive ones. I fixed doctests that need changing when a pynac function is added to the Sage library and then, because I changed a docstring in that file, another doctest failed. Phew..
</p>
TicketkcrismanSun, 09 Oct 2011 01:29:49 GMTdependencies changed
https://trac.sagemath.org/ticket/11143#comment:30
https://trac.sagemath.org/ticket/11143#comment:30
<ul>
<li><strong>dependencies</strong>
changed from <em>#11513</em> to <em>#11513, 11885</em>
</li>
</ul>
<p>
Impressive work. No guarantees that I'll be able to look through this long patch with a fine-tooth comb anytime soon, but this will be a great addition - I really like <code>Ci</code> and <code>Si</code> being in.
</p>
<pre class="wiki"> \operatorname{li}(x) = \int_0^z \frac{dt}{\ln(t)} = \operatorname{Ei}(\ln(x))
</pre><p>
?? What happened to the x in the middle?
</p>
<p>
Also, what relation does this function bear to <code>Li</code> (I assume it's the <code>\int_0</code> as opposed to <code>\int_2</code>, if I recall correctly), and why is that not mentioned? See <a class="closed ticket" href="https://trac.sagemath.org/ticket/7357" title="enhancement: Add non-offset logarithmic integral, Li (closed: duplicate)">#7357</a>. I have to say that the names of the functions are ... very long. Is there a problem with the fairly standard <code>Li</code> and <code>li</code>?
</p>
<p>
See also <a class="closed ticket" href="https://trac.sagemath.org/ticket/3401" title="enhancement: Make Li symbolic and work with complex input (closed: fixed)">#3401</a>, though I don't know if that is <em>directly</em> relevant for this particular set of functions.
</p>
TicketkcrismanSun, 09 Oct 2011 01:30:38 GMTdependencies changed
https://trac.sagemath.org/ticket/11143#comment:31
https://trac.sagemath.org/ticket/11143#comment:31
<ul>
<li><strong>dependencies</strong>
changed from <em>#11513, 11885</em> to <em>#11513, #11885</em>
</li>
</ul>
TicketbenjaminfjonesSun, 09 Oct 2011 02:02:02 GMT
https://trac.sagemath.org/ticket/11143#comment:32
https://trac.sagemath.org/ticket/11143#comment:32
<p>
@kcrisman - Yes, thanks, I just spotted that typo in the docstring for <code>exp_integral_li</code> while I was commenting on the other tickets you cc'd me on.
</p>
<p>
The function names are long. I wanted to choose a common prefix for all the exponential integrals. I think burcin suggested <code>exp_integral</code> originally. I think the problem with <code>li</code> and <code>Li</code>, or <code>En</code> and <code>Ei</code>, etc.. is that the name is very short and not very informative unless you are familiar with all the different varieties of standard exponential integrals. Also, I think the short two-letter names would be easy to mix up, especially <code>li</code> and <code>Li</code>. Yes, you're right, the difference between those logarithmic integrals is the constant <code>\int_0^2 1/log(t) dt</code>.
</p>
<p>
I made some comments on <a class="closed ticket" href="https://trac.sagemath.org/ticket/7357" title="enhancement: Add non-offset logarithmic integral, Li (closed: duplicate)">#7357</a> and <a class="closed ticket" href="https://trac.sagemath.org/ticket/3401" title="enhancement: Make Li symbolic and work with complex input (closed: fixed)">#3401</a>. Basically, I think it makes sense to roll the issues in those two tickets into this one since this one is an overhaul of the exponential integral functions with the aim to make them all symbolic and organize them in the same module.
</p>
TicketbenjaminfjonesSun, 09 Oct 2011 02:04:14 GMT
https://trac.sagemath.org/ticket/11143#comment:33
https://trac.sagemath.org/ticket/11143#comment:33
<p>
Sorry for the double comment. I remembered the rational for the common prefix. Burcin point out that once a user knows about one exponential integral function, they can type:<code>exp_integral<tab></code> and see the list of all of them. That wouldn't be possible if the names are just the standard mathematical notation li, Li, En, Ei, etc..
</p>
TicketkcrismanMon, 10 Oct 2011 02:21:19 GMT
https://trac.sagemath.org/ticket/11143#comment:34
https://trac.sagemath.org/ticket/11143#comment:34
<p>
That second comment about tab-completion makes sense. I just think it would be helpful to have easy-to-find aliases as well. <a class="ext-link" href="http://reference.wolfram.com/mathematica/guide/ErrorAndExponentialIntegralFunctions.html"><span class="icon"></span>Here</a> are Mathematica's names. I understand the concern about the standard notation, but it <em>is</em> standard, and I would never think to look for log integral under <code>exp_integral<tab></code>, if you catch my drift - and I do know it can be written as one.
</p>
<p>
Sorry about the comments on the other tickets about naming conventions - feel free to ignore those, I read this update last.
</p>
TicketbenjaminfjonesTue, 11 Oct 2011 22:25:01 GMT
https://trac.sagemath.org/ticket/11143#comment:35
https://trac.sagemath.org/ticket/11143#comment:35
<p>
I see your point. How about the following names:
</p>
<ul><li><code>exp_integral_e</code>
</li><li><code>exp_integral_e1</code>
</li><li><code>exp_integral_ei</code>
</li><li><code>log_integral</code> (for li)
</li><li><code>log_integral_offset</code> for (Li)
</li><li><code>cos_integral</code>
</li><li><code>sin_integral</code>
</li><li><code>sinh_integral</code>
</li><li><code>cosh_integral</code>
</li></ul><p>
... and maybe aliases for the usual mathematical names: <code>li, Li, En, Ei, E1, si, ci, shi, chi</code> ? Perhaps that would be too many new names in the global name space?
</p>
TicketkcrismanWed, 12 Oct 2011 01:40:38 GMTstatus changed
https://trac.sagemath.org/ticket/11143#comment:36
https://trac.sagemath.org/ticket/11143#comment:36
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>needs_work</em>
</li>
</ul>
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/11143#comment:35" title="Comment 35">benjaminfjones</a>:
</p>
<blockquote class="citation">
<p>
I see your point. How about the following names:
</p>
<ul><li><code>exp_integral_e</code>
</li><li><code>exp_integral_e1</code>
</li><li><code>exp_integral_ei</code>
</li><li><code>log_integral</code> (for li)
</li><li><code>log_integral_offset</code> for (Li)
</li><li><code>cos_integral</code>
</li><li><code>sin_integral</code>
</li><li><code>sinh_integral</code>
</li><li><code>cosh_integral</code>
</li></ul></blockquote>
<p>
This could work, and is easier to understand. Maybe <code>exp_integral<tab></code> could also bring up some command which gave general help for this whole module... ?
</p>
<blockquote class="citation">
<p>
... and maybe aliases for the usual mathematical names: <code>li, Li, En, Ei, E1, si, ci, shi, chi</code> ? Perhaps that would be too many new names in the global name space?
</p>
</blockquote>
<p>
You're right that it's a lot. On the other hand, <code>Si</code> and <code>li/Li</code> are fairly standard... I think it might be worth asking on sage-devel as to how many of these would be useful. I definitely think that things which are global in both Mma and Maple should be okay. See <a class="ext-link" href="http://www.maplesoft.com/support/help/Maple/view.aspx?path=Ci"><span class="icon"></span>Maple help</a> and e.g. <a class="ext-link" href="http://functions.wolfram.com/GammaBetaErf/SinIntegral/"><span class="icon"></span>this Mathematica help</a>. Seems like Maple is more likely to support the standard notation as a shortcut. But at the very least your ideas above are better than the initial one.
</p>
<p>
I'll put this as 'needs work' for this reason.
</p>
<hr />
<p>
Thank you so much for the hard work and at times surely boring work improving this. There are so many things <em>already in Sage</em> which we just need to make easier for the end user.
</p>
TicketbenjaminfjonesWed, 22 Feb 2012 22:16:05 GMTattachment set
https://trac.sagemath.org/ticket/11143
https://trac.sagemath.org/ticket/11143
<ul>
<li><strong>attachment</strong>
set to <em>trac_11143_v2.patch</em>
</li>
</ul>
<p>
renamed functions according to trac comments and rebased to 5.0.beta5
</p>
TicketbenjaminfjonesWed, 22 Feb 2012 22:21:08 GMTstatus, description changed
https://trac.sagemath.org/ticket/11143#comment:37
https://trac.sagemath.org/ticket/11143#comment:37
<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/11143?action=diff&version=37">diff</a>)
</li>
</ul>
<p>
Since all the dependencies have been merged I thought I would rebase this ticket and make the outstanding changes from the last comment. I've changed the names of the functions in the new module <code>sage/functions/exp_integral.py</code> according to my proposal in comment <a class="ticket" href="https://trac.sagemath.org/ticket/11143#comment:36" title="Comment 36">36</a> and added top-level aliases <code>li, si, ci, shi, chi</code>.
</p>
TicketkcrismanFri, 09 Mar 2012 20:14:27 GMT
https://trac.sagemath.org/ticket/11143#comment:38
https://trac.sagemath.org/ticket/11143#comment:38
<blockquote class="citation">
<p>
Since all the dependencies have been merged I thought I would rebase this ticket and make the outstanding changes from the last comment. I've changed the names of the functions in the new module <code>sage/functions/exp_integral.py</code> according to my proposal in comment <a class="ticket" href="https://trac.sagemath.org/ticket/11143#comment:36" title="Comment 36">36</a> and added top-level aliases <code>li, si, ci, shi, chi</code>.
</p>
</blockquote>
<p>
This came up while preparing for a Sage talk today - I tried
</p>
<pre class="wiki">sage: integrate(log(x-1)*e^x,x)
e*expintegral_e(1, -x + 1) + e^x*log(x - 1)
</pre><p>
and of course it doesn't LaTeX very nicely.
</p>
<p>
I'll try to look at this soon. I already know that we would need to make <code>si</code> into <code>Si</code>, etc., because that <em>is</em> the standard notation (first letter capitalized, see all the references above), but I can make a reviewer patch which does this. But it sounds like this should be finally ready to go. Sorry for the long process here!
</p>
TicketbenjaminfjonesFri, 09 Mar 2012 20:54:30 GMT
https://trac.sagemath.org/ticket/11143#comment:39
https://trac.sagemath.org/ticket/11143#comment:39
<p>
I can fix the latex issues if you haven't started already. I have the afternoon off.
</p>
TicketkcrismanFri, 09 Mar 2012 20:57:53 GMT
https://trac.sagemath.org/ticket/11143#comment:40
https://trac.sagemath.org/ticket/11143#comment:40
<p>
I don't know that there <em>are</em> any LaTeX issues; the example above was with Sage 4.8! I suppose you can try that example with this patch to see.
</p>
<p>
I only commented to remind myself that we should have <code>Si</code> and not <code>si</code>, in line with Maple and with Mathematica's documentation on the 'usual' name for this function (though not its command). It keeps this patch on my mind. If there is something wrong, though, you can definitely fix it!
</p>
TicketdavidloefflerMon, 26 Mar 2012 15:31:55 GMT
https://trac.sagemath.org/ticket/11143#comment:41
https://trac.sagemath.org/ticket/11143#comment:41
<p>
Apply trac_11143_v2.patch
</p>
<p>
(for patchbot)
</p>
TicketdavidloefflerMon, 26 Mar 2012 18:06:48 GMTstatus changed; work_issues set
https://trac.sagemath.org/ticket/11143#comment:42
https://trac.sagemath.org/ticket/11143#comment:42
<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>rebase to 5.0.beta10</em>
</li>
</ul>
<p>
This patch doesn't apply to the current Sage beta -- see patchbot logs.
</p>
TicketbenjaminfjonesMon, 26 Mar 2012 20:07:39 GMTattachment set
https://trac.sagemath.org/ticket/11143
https://trac.sagemath.org/ticket/11143
<ul>
<li><strong>attachment</strong>
set to <em>trac_11143_v2.2.patch</em>
</li>
</ul>
<p>
rebase to 5.0.beta10
</p>
TicketbenjaminfjonesMon, 26 Mar 2012 20:08:39 GMT
https://trac.sagemath.org/ticket/11143#comment:43
https://trac.sagemath.org/ticket/11143#comment:43
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/11143#comment:42" title="Comment 42">davidloeffler</a>:
</p>
<blockquote class="citation">
<p>
This patch doesn't apply to the current Sage beta -- see patchbot logs.
</p>
</blockquote>
<p>
Thanks for updating the ticket description. I've rebased my patch to 5.0.beta10.
</p>
TicketdavidloefflerMon, 26 Mar 2012 20:14:20 GMTstatus changed
https://trac.sagemath.org/ticket/11143#comment:44
https://trac.sagemath.org/ticket/11143#comment:44
<ul>
<li><strong>status</strong>
changed from <em>needs_work</em> to <em>needs_review</em>
</li>
</ul>
TicketJoalHeagneyWed, 28 Mar 2012 23:40:11 GMT
https://trac.sagemath.org/ticket/11143#comment:45
https://trac.sagemath.org/ticket/11143#comment:45
<p>
Hi guys. I don't know if this even applies, because I discovered this behaviour on version 4.8, with the patch applied (And it seems to apply to limit rather than anything else.)
However, if I enter the following code:
</p>
<pre class="wiki">def fracintegral(func,n, xsub=x,a=0):
t = var('t')
assume(t > a)
assume(x > a)
return integrate(((x-t)^(n-1))*func(t),t,a,x)/gamma(n)
a = fracintegral(sin(x),1/2);a
</pre><p>
I get the following returned:
</p>
<pre class="wiki">-1/2*(sqrt(x)*sin(x)*exp_integral_e(1/2, -I*x) +
sqrt(x)*sin(x)*exp_integral_e(1/2, I*x) +
I*sqrt(x)*cos(x)*exp_integral_e(1/2, -I*x) -
I*sqrt(x)*cos(x)*exp_integral_e(1/2, I*x) -
2*limit(1/2*sqrt(-t)*sin(x)*exp_integral_e(1/2, -I*t) +
1/2*sqrt(-t)*sin(x)*exp_integral_e(1/2, I*t) -
1/2*I*sqrt(-t)*cos(x)*exp_integral_e(1/2, -I*t) +
1/2*I*sqrt(-t)*cos(x)*exp_integral_e(1/2, I*t), t, 0, minus))/sqrt(pi)
</pre><p>
If I copy/paste this into a new sage notebook cell, I get the following error:
</p>
<pre class="wiki">Traceback (most recent call last): 1/2*I*sqrt(-t)*cos(x)*exp_integral_e(1/2, -I*t) +
File "", line 1, in <module>
File "/tmp/tmpbIxhPU/___code___.py", line 10, in <module>
_sage_const_1 /_sage_const_2 *I*sqrt(-t)*cos(x)*exp_integral_e(_sage_const_1 /_sage_const_2 , I*t), t, _sage_const_0 , minus))/sqrt(pi)
NameError: name 'minus' is not defined
</pre><p>
If I fix up the minus by doing this,
</p>
<pre class="wiki">-1/2*(sqrt(x)*sin(x)*exp_integral_e(1/2, -I*x) +
sqrt(x)*sin(x)*exp_integral_e(1/2, I*x) +
I*sqrt(x)*cos(x)*exp_integral_e(1/2, -I*x) -
I*sqrt(x)*cos(x)*exp_integral_e(1/2, I*x) -
2*limit(1/2*sqrt(-t)*sin(x)*exp_integral_e(1/2, -I*t) +
1/2*sqrt(-t)*sin(x)*exp_integral_e(1/2, I*t) -
1/2*I*sqrt(-t)*cos(x)*exp_integral_e(1/2, -I*t) +
1/2*I*sqrt(-t)*cos(x)*exp_integral_e(1/2, I*t), t, 0, 'minus'))/sqrt(pi)
</pre><p>
I get this error:
</p>
<pre class="wiki">Traceback (most recent call last): 1/2*I*sqrt(-t)*cos(x)*exp_integral_e(1/2, -I*t) +
File "", line 1, in <module>
File "/tmp/tmpI2jAGB/___code___.py", line 10, in <module>
_sage_const_1 /_sage_const_2 *I*sqrt(-t)*cos(x)*exp_integral_e(_sage_const_1 /_sage_const_2 , I*t), t, _sage_const_0 , 'minus'))/sqrt(pi)
File "/home/joal/bin/sage-4.8-linux-64bit-ubuntu_10.04.3_lts-x86_64-Linux/local/lib/python2.6/site-packages/sage/calculus/calculus.py", line 1131, in limit
raise ValueError, "call the limit function like this, e.g. limit(expr, x=2)."
ValueError: call the limit function like this, e.g. limit(expr, x=2).
</pre><p>
Then if I write it up in correct limit syntax like so:
</p>
<pre class="wiki">b = 2*limit(1/2*sqrt(-t)*sin(x)*exp_integral_e(1/2, -I*t) +
1/2*sqrt(-t)*sin(x)*exp_integral_e(1/2, I*t) -
1/2*I*sqrt(-t)*cos(x)*exp_integral_e(1/2, -I*t) +
1/2*I*sqrt(-t)*cos(x)*exp_integral_e(1/2, I*t), t=0, dir='minus'); b
</pre><p>
I get literally nothing from the notebook cell. If I then enter b and evaluate in the next cell I get this:
</p>
<pre class="wiki">2*limit(1/2*I*sqrt(t)*sin(x)*exp_integral_e(1/2, -I*t) +
1/2*I*sqrt(t)*sin(x)*exp_integral_e(1/2, I*t) +
1/2*sqrt(t)*cos(x)*exp_integral_e(1/2, -I*t) -
1/2*sqrt(t)*cos(x)*exp_integral_e(1/2, I*t), t, 0, minus)
</pre><p>
This is all with Pretty Printing turned off. If I turn on Pretty Printing, then the reply from the fracintegral call (on trig functions and exponents) is this:
</p>
<pre class="wiki">Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "_sage_input_35.py", line 10, in <module>
exec compile(u'open("___code___.py","w").write("# -*- coding: utf-8 -*-\\n" + _support_.preparse_worksheet_cell(base64.b64decode("YSA9IGZyYWNpbnRlZ3JhbChzaW4oeCksMS8yKTth"),globals())+"\\n"); execfile(os.path.abspath("___code___.py"))
File "", line 1, in <module>
File "/tmp/tmpOvxXQw/___code___.py", line 3, in <module>
exec compile(u'a = fracintegral(sin(x),_sage_const_1 /_sage_const_2 );a
File "", line 1, in <module>
File "/home/joal/bin/sage-4.8-linux-64bit-ubuntu_10.04.3_lts-x86_64-Linux/local/lib/python2.6/site-packages/sage/misc/latex.py", line 2243, in pretty_print
view(object)
File "/home/joal/bin/sage-4.8-linux-64bit-ubuntu_10.04.3_lts-x86_64-Linux/local/lib/python2.6/site-packages/sage/misc/latex.py", line 1969, in view
s = _latex_file_(objects, title=title, sep=sep, tiny=tiny, debug=debug, **latex_options)
File "/home/joal/bin/sage-4.8-linux-64bit-ubuntu_10.04.3_lts-x86_64-Linux/local/lib/python2.6/site-packages/sage/misc/latex.py", line 1624, in _latex_file_
L = latex(x)
File "/home/joal/bin/sage-4.8-linux-64bit-ubuntu_10.04.3_lts-x86_64-Linux/local/lib/python2.6/site-packages/sage/misc/latex.py", line 875, in __call__
return LatexExpr(x._latex_())
File "expression.pyx", line 667, in sage.symbolic.expression.Expression._latex_ (sage/symbolic/expression.cpp:4121)
File "ring.pyx", line 596, in sage.symbolic.ring.SymbolicRing._latex_element_ (sage/symbolic/ring.cpp:6461)
File "pynac.pyx", line 433, in sage.symbolic.pynac.py_latex_function (sage/symbolic/pynac.cpp:4702)
File "pynac.pyx", line 407, in sage.symbolic.pynac.py_latex_function_pystring (sage/symbolic/pynac.cpp:4328)
TypeError: _limit_latex_() takes exactly 4 arguments (5 given)
</pre><p>
Let me know if I should put this into another ticket for limit, but kcrisman asked me to put this up here first.
</p>
TicketbenjaminfjonesFri, 06 Apr 2012 18:50:24 GMTattachment set
https://trac.sagemath.org/ticket/11143
https://trac.sagemath.org/ticket/11143
<ul>
<li><strong>attachment</strong>
set to <em>trac_11143_v2.3.patch</em>
</li>
</ul>
<p>
removed trailing whitespace
</p>
TicketbenjaminfjonesFri, 06 Apr 2012 18:51:22 GMTdescription changed; dependencies deleted
https://trac.sagemath.org/ticket/11143#comment:46
https://trac.sagemath.org/ticket/11143#comment:46
<ul>
<li><strong>dependencies</strong>
<em>#11513, #11885</em> deleted
</li>
<li><strong>description</strong>
modified (<a href="/ticket/11143?action=diff&version=46">diff</a>)
</li>
</ul>
TicketzimmermaFri, 25 May 2012 09:03:18 GMTstatus, work_issues changed
https://trac.sagemath.org/ticket/11143#comment:47
https://trac.sagemath.org/ticket/11143#comment:47
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>needs_work</em>
</li>
<li><strong>work_issues</strong>
changed from <em>rebase to 5.0.beta10</em> to <em>define expintegral_ei</em>
</li>
</ul>
<p>
while looking in the sources for the old name <code>expintegral_e</code> I found the following
instance:
</p>
<pre class="wiki">sage: search_src("expintegral_e")
functions/exp_integral.py:393: x*log_integral(x) - expintegral_ei(2*log(x))
sage: expintegral_ei?
Object `expintegral_ei` not found.
</pre><p>
That should be fixed too.
</p>
<p>
Paul
</p>
<p>
PS: the patch applied cleanly to 5.0, thus I removed the "rebase to 5.0.beta10" work issue
</p>
TicketbenjaminfjonesFri, 25 May 2012 17:55:19 GMTattachment set
https://trac.sagemath.org/ticket/11143
https://trac.sagemath.org/ticket/11143
<ul>
<li><strong>attachment</strong>
set to <em>trac_11143_v2.4.patch</em>
</li>
</ul>
TicketbenjaminfjonesFri, 25 May 2012 17:57:48 GMTstatus changed; work_issues deleted
https://trac.sagemath.org/ticket/11143#comment:48
https://trac.sagemath.org/ticket/11143#comment:48
<ul>
<li><strong>status</strong>
changed from <em>needs_work</em> to <em>needs_review</em>
</li>
<li><strong>work_issues</strong>
<em>define expintegral_ei</em> deleted
</li>
</ul>
<p>
Good catch, I've added the maxima conversion for <code>expintegral_ei</code> in the new patch. I've also changed the top level aliases <code>si</code> -> <code>Si</code>, <code>ci</code> -> <code>Ci</code>, etc.. to match standard notation. The added file <code>exp_integral.py</code> passes all tests, I'm running the full test suite now.
</p>
<p>
Patchbot: apply <a class="missing attachment">trac_11143_v2.4.patch </a>
</p>
TicketbenjaminfjonesFri, 25 May 2012 18:09:29 GMTkeywords changed
https://trac.sagemath.org/ticket/11143#comment:49
https://trac.sagemath.org/ticket/11143#comment:49
<ul>
<li><strong>keywords</strong>
<em>sd40.5</em> added
</li>
</ul>
TicketdsmSat, 26 May 2012 17:18:13 GMT
https://trac.sagemath.org/ticket/11143#comment:50
https://trac.sagemath.org/ticket/11143#comment:50
<p>
Looks good! A few quirks I've noticed:
</p>
<p>
(1) li behaves a little differently with respect to autoevaluation at 0:
</p>
<pre class="wiki">sage: Si(0)
0
sage: Shi(0)
0
sage: li(0)
log_integral(0)
sage: li(0).simplify()
0
sage: li(0).n()
0.000000000000000
</pre><p>
(2) In the (probably semi-deprecated; it works with Python floats) exponential_integral_1, we should special-case 0:
</p>
<pre class="wiki">sage: exp_integral_e1(0.01)
4.03792957653811
sage: exponential_integral_1(0.01)
4.037929576538114
sage: exp_integral_e1(0)
exp_integral_e1(0)
sage: exp_integral_e1(0).n()
+infinity
sage: exponential_integral_1(0)
---------------------------------------------------------------------------
PariError Traceback (most recent call last)
/Users/mcneil/sagedev/sage-5.1.beta0/devel/sage-hack/sage/<ipython console> in <module>()
/Users/mcneil/sagedev/sage-5.1.beta0/local/lib/python2.7/site-packages/sage/functions/exp_integral.pyc in exponential_integral_1(x, n)
1327 from sage.libs.pari.all import pari
1328 if n <= 0:
-> 1329 return float(pari(x).eint1())
1330 else:
1331 return [float(z) for z in pari(x).eint1(n)]
/Users/mcneil/sagedev/sage-5.1.beta0/local/lib/python2.7/site-packages/sage/libs/pari/gen.so in sage.libs.pari.gen._pari_trap (sage/libs/pari/gen.c:49907)()
PariError: (5)
</pre><p>
(3) There's something going on with integration I don't understand:
</p>
<pre class="wiki">
sage: integrate(sinh_integral(x), x)
x*sinh_integral(x) - cosh(x)
sage: integrate(sinh_integral(x), x, 0, 1/2)
-cosh(1/2) + 1/2*sinh_integral(1/2) + 1
sage: integrate(sinh_integral(x), x, 0, 1/2).n()
0.125872409703453
sage:
sage: integrate(sinh_integral(x), x, 0.0, 0.5)
0.125872409703 + 1.57079632679*I
</pre><p>
IOW, somehow we pick up a pi/2 I, and it probably happens on our side:
</p>
<pre class="wiki">
In [7]: quad(lambda x: shi(x), [0, 0.5])
Out[7]: mpf('0.12587240970345281')
</pre>
TicketkcrismanSat, 26 May 2012 17:26:33 GMT
https://trac.sagemath.org/ticket/11143#comment:51
https://trac.sagemath.org/ticket/11143#comment:51
<p>
This is really great. I've checked a number of things against Wolfram Alpha, doc has lots of great examples, excellent work. Great catches, Doug.
</p>
<p>
We can now completely remove <code>exp_int</code>, because it was deprecated over two years ago.
</p>
<p>
See <a class="closed ticket" href="https://trac.sagemath.org/ticket/3401" title="enhancement: Make Li symbolic and work with complex input (closed: fixed)">#3401</a> for making the offset log integral symbolic as well. William would really like this.
</p>
TicketkcrismanSat, 26 May 2012 18:07:51 GMT
https://trac.sagemath.org/ticket/11143#comment:52
https://trac.sagemath.org/ticket/11143#comment:52
<p>
Okay, I've reported the issue with Maxima using the wrong branch for <code>Shi</code> at <a class="ext-link" href="https://sourceforge.net/tracker/?func=detail&aid=3529992&group_id=4933&atid=104933"><span class="icon"></span>this bug tracker ticket</a>.
</p>
<pre class="wiki">(%i30) float(expintegral_shi(1/2));
(%o30) 3.141592653589793*%i+0.506996749819667
</pre>
TicketdsmSat, 26 May 2012 18:11:35 GMT
https://trac.sagemath.org/ticket/11143#comment:53
https://trac.sagemath.org/ticket/11143#comment:53
<p>
Thanks, kcrisman. Since after real-world discussions it appears that the integration difficulty is another Maxima quirk, I don't think we should hold up approving this, especially because it can be worked around. I do think it's worth warning the user, and the example will serve as a reminder to us that it can be removed when we update to a version of Maxima which finally fixes it, 'cause the doctest will fail.
</p>
<p>
So I propose adding the following to EXAMPLES for sinh_integral:
</p>
<pre class="wiki">
Note that due to some problems with the way Maxima handles these
expressions, definite integrals can sometimes give unexpected
results (typically when using inexact endpoints) due to
inconsistent branching::
sage: integrate(sinh_integral(x), x, 0, 1/2)
-cosh(1/2) + 1/2*sinh_integral(1/2) + 1
sage: integrate(sinh_integral(x), x, 0, 1/2).n() # right
0.125872409703453
sage: integrate(sinh_integral(x), x, 0, 0.5).n() # wrong!
0.125872409703453 + 1.57079632679490*I
</pre>
TicketbenjaminfjonesSat, 26 May 2012 20:10:32 GMTattachment set
https://trac.sagemath.org/ticket/11143
https://trac.sagemath.org/ticket/11143
<ul>
<li><strong>attachment</strong>
set to <em>trac_11143_v2.5.patch</em>
</li>
</ul>
<p>
addresses log_integral(0) -> 0, exponential_integral_1(0) -> Infinity, sinh_integral issues, etc..
</p>
TicketbenjaminfjonesSat, 26 May 2012 20:14:05 GMT
https://trac.sagemath.org/ticket/11143#comment:54
https://trac.sagemath.org/ticket/11143#comment:54
<p>
The new patch should take care of dsm's (1), (2), (3) and kcrisman's <code>exp_int</code> removal. Please test the new automatic simplification code in <code>log_integral</code> and <code>exponential_integral_1</code>.
</p>
<p>
Patchbot: apply <a class="attachment" href="https://trac.sagemath.org/attachment/ticket/11143/trac_11143_v2.5.patch" title="Attachment 'trac_11143_v2.5.patch' in Ticket #11143">trac_11143_v2.5.patch</a><a class="trac-rawlink" href="https://trac.sagemath.org/raw-attachment/ticket/11143/trac_11143_v2.5.patch" title="Download"></a>
</p>
TicketkcrismanSat, 26 May 2012 20:57:31 GMT
https://trac.sagemath.org/ticket/11143#comment:55
https://trac.sagemath.org/ticket/11143#comment:55
<p>
I don't like this.
</p>
<pre class="wiki">sage: li(0)
0
sage: type(li(0))
<type 'sage.rings.integer.Integer'>
sage: Si(0)
0
sage: type(Si(0))
<type 'sage.rings.integer.Integer'>
</pre><p>
The reason is
</p>
<pre class="wiki"> # special case: z = 0
if isinstance(z, Expression):
if z.is_trivial_zero():
return z
else:
if not z:
return z
</pre><p>
type code, because of course the zero <code>z</code> we input is not an expression, but is <code>not z</code>, so we return the <strong>Integer</strong> zero instead of the <strong>symbolic</strong> zero.
</p>
<p>
Of course, we're inconsistent here:
</p>
<pre class="wiki">sage: sin(0)
0
sage: type(sin(0))
<type 'int'>
</pre><p>
Oops. But under the philosophy of
</p>
<pre class="wiki">sage: f(x) = x^2
sage: f(0)
0
sage: type(f(0))
<type 'sage.symbolic.expression.Expression'>
</pre><p>
I think we should return an <code>Expression</code>.
</p>
TicketbenjaminfjonesSun, 27 May 2012 02:08:20 GMT
https://trac.sagemath.org/ticket/11143#comment:56
https://trac.sagemath.org/ticket/11143#comment:56
<p>
For the record, I think we should try as much as possible to return outputs with the same parent as the input (whenever this makes sense). For <code>li(int(0))</code> we should get <code>int(0)</code>, for <code>li(Integer(0))</code> we should get <code>Integer(0)</code>, etc..
</p>
TicketkcrismanSun, 27 May 2012 04:27:03 GMTdescription changed
https://trac.sagemath.org/ticket/11143#comment:57
https://trac.sagemath.org/ticket/11143#comment:57
<ul>
<li><strong>description</strong>
modified (<a href="/ticket/11143?action=diff&version=57">diff</a>)
</li>
</ul>
TicketwasMon, 28 May 2012 19:34:36 GMTstatus, reviewer changed
https://trac.sagemath.org/ticket/11143#comment:58
https://trac.sagemath.org/ticket/11143#comment:58
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>positive_review</em>
</li>
<li><strong>reviewer</strong>
changed from <em>Burcin Erocal, Karl-Dieter Crisman</em> to <em>Burcin Erocal, Karl-Dieter Crisman, William Stein</em>
</li>
</ul>
<p>
Looks good to me. I've attached a little referee patch.
</p>
TicketbenjaminfjonesMon, 28 May 2012 20:18:07 GMTdescription changed
https://trac.sagemath.org/ticket/11143#comment:59
https://trac.sagemath.org/ticket/11143#comment:59
<ul>
<li><strong>description</strong>
modified (<a href="/ticket/11143?action=diff&version=59">diff</a>)
</li>
</ul>
<p>
Thanks! I'll update the ticket description.
</p>
TicketkcrismanMon, 28 May 2012 20:31:58 GMT
https://trac.sagemath.org/ticket/11143#comment:60
https://trac.sagemath.org/ticket/11143#comment:60
<p>
The reviewer patch introduces an erroneous hunk with a backtick in a random line.
</p>
TicketbenjaminfjonesMon, 28 May 2012 20:36:20 GMTattachment set
https://trac.sagemath.org/ticket/11143
https://trac.sagemath.org/ticket/11143
<ul>
<li><strong>attachment</strong>
set to <em>trac-11143-ref.2.patch</em>
</li>
</ul>
TicketbenjaminfjonesMon, 28 May 2012 20:37:10 GMTdescription changed
https://trac.sagemath.org/ticket/11143#comment:61
https://trac.sagemath.org/ticket/11143#comment:61
<ul>
<li><strong>description</strong>
modified (<a href="/ticket/11143?action=diff&version=61">diff</a>)
</li>
</ul>
TicketwasMon, 28 May 2012 20:38:53 GMTattachment set
https://trac.sagemath.org/ticket/11143
https://trac.sagemath.org/ticket/11143
<ul>
<li><strong>attachment</strong>
set to <em>trac-11143-ref.patch</em>
</li>
</ul>
<p>
fixed
</p>
TicketJoalHeagneySat, 09 Jun 2012 05:26:35 GMT
https://trac.sagemath.org/ticket/11143#comment:62
https://trac.sagemath.org/ticket/11143#comment:62
<p>
With the patches applied to 5.0, my fractional integral code works on sine functions, but I still get the following error if pretty printing is on. Is there a trac post for this?
</p>
<pre class="wiki">def fracintegral(func,xsub,n,a=0):
t = var('t')
assume(t > a)
assume(x > a)
return integrate((x-t)^(n-1)*func.subs({xsub:t}),t,a,x)/gamma(n)
a = fracintegral(sin(x),x,1/2)
a
</pre><p>
Returns this on the call to a (but not on the assignment of a =):
</p>
<pre class="wiki">Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "_sage_input_19.py", line 10, in <module>
exec compile(u'open("___code___.py","w").write("# -*- coding: utf-8 -*-\\n" + _support_.preparse_worksheet_cell(base64.b64decode("YQ=="),globals())+"\\n"); execfile(os.path.abspath("___code___.py"))
File "", line 1, in <module>
File "/tmp/tmpJfuEaN/___code___.py", line 2, in <module>
exec compile(u'a
File "", line 1, in <module>
File "/home/joal/bin/sage-5.0/local/lib/python2.7/site-packages/sage/misc/latex.py", line 2280, in pretty_print
view(object)
File "/home/joal/bin/sage-5.0/local/lib/python2.7/site-packages/sage/misc/latex.py", line 2006, in view
s = _latex_file_(objects, title=title, sep=sep, tiny=tiny, debug=debug, **latex_options)
File "/home/joal/bin/sage-5.0/local/lib/python2.7/site-packages/sage/misc/latex.py", line 1661, in _latex_file_
L = latex(x)
File "/home/joal/bin/sage-5.0/local/lib/python2.7/site-packages/sage/misc/latex.py", line 909, in __call__
return LatexExpr(x._latex_())
File "expression.pyx", line 815, in sage.symbolic.expression.Expression._latex_ (sage/symbolic/expression.cpp:4898)
File "ring.pyx", line 605, in sage.symbolic.ring.SymbolicRing._latex_element_ (sage/symbolic/ring.cpp:6658)
File "pynac.pyx", line 433, in sage.symbolic.pynac.py_latex_function (sage/symbolic/pynac.cpp:4817)
File "pynac.pyx", line 407, in sage.symbolic.pynac.py_latex_function_pystring (sage/symbolic/pynac.cpp:4443)
TypeError: _limit_latex_() takes exactly 4 arguments (5 given)
</pre>
TicketjdemeyerMon, 18 Jun 2012 13:35:56 GMTmilestone changed
https://trac.sagemath.org/ticket/11143#comment:63
https://trac.sagemath.org/ticket/11143#comment:63
<ul>
<li><strong>milestone</strong>
changed from <em>sage-5.1</em> to <em>sage-5.2</em>
</li>
</ul>
TicketjdemeyerThu, 28 Jun 2012 08:32:06 GMTstatus changed
https://trac.sagemath.org/ticket/11143#comment:64
https://trac.sagemath.org/ticket/11143#comment:64
<ul>
<li><strong>status</strong>
changed from <em>positive_review</em> to <em>needs_work</em>
</li>
</ul>
<p>
This doesn't apply cleanly to sage-5.1.beta6:
</p>
<pre class="wiki">applying /release/merger/patches/trac_11143_v2.5.patch
patching file sage/functions/all.py
Hunk #1 succeeded at 25 with fuzz 1 (offset 0 lines).
patching file sage/interfaces/maxima_lib.py
Hunk #1 FAILED at 1354
1 out of 1 hunks FAILED -- saving rejects to file sage/interfaces/maxima_lib.py.rej
abort: patch failed to apply
</pre>
TicketkcrismanThu, 28 Jun 2012 13:17:56 GMT
https://trac.sagemath.org/ticket/11143#comment:65
https://trac.sagemath.org/ticket/11143#comment:65
<p>
This is a tiny thing due to the Lambert W function, <a class="closed ticket" href="https://trac.sagemath.org/ticket/11888" title="defect: Sage is missing the lambert_w function (closed: fixed)">#11888</a>. I'll upload a clean one to beta6 momentarily.
</p>
TicketkcrismanThu, 28 Jun 2012 13:22:25 GMTattachment set
https://trac.sagemath.org/ticket/11143
https://trac.sagemath.org/ticket/11143
<ul>
<li><strong>attachment</strong>
set to <em>trac_11143-v2.5-rebased.patch</em>
</li>
</ul>
<p>
Rebased to 5.1.beta6
</p>
TicketkcrismanThu, 28 Jun 2012 13:24:31 GMTstatus, description changed
https://trac.sagemath.org/ticket/11143#comment:66
https://trac.sagemath.org/ticket/11143#comment:66
<ul>
<li><strong>status</strong>
changed from <em>needs_work</em> to <em>positive_review</em>
</li>
<li><strong>description</strong>
modified (<a href="/ticket/11143?action=diff&version=66">diff</a>)
</li>
</ul>
<p>
Patchbot:
</p>
<p>
Apply to the Sage library:
</p>
<ol><li><a class="attachment" href="https://trac.sagemath.org/attachment/ticket/11143/trac_11143-v2.5-rebased.patch" title="Attachment 'trac_11143-v2.5-rebased.patch' in Ticket #11143">trac_11143-v2.5-rebased.patch</a><a class="trac-rawlink" href="https://trac.sagemath.org/raw-attachment/ticket/11143/trac_11143-v2.5-rebased.patch" title="Download"></a>
</li><li><a class="attachment" href="https://trac.sagemath.org/attachment/ticket/11143/trac-11143-ref.2.patch" title="Attachment 'trac-11143-ref.2.patch' in Ticket #11143">trac-11143-ref.2.patch</a><a class="trac-rawlink" href="https://trac.sagemath.org/raw-attachment/ticket/11143/trac-11143-ref.2.patch" title="Download"></a>
</li></ol><p>
This should be fine.
</p>
TicketkcrismanThu, 28 Jun 2012 16:15:56 GMTstatus changed
https://trac.sagemath.org/ticket/11143#comment:67
https://trac.sagemath.org/ticket/11143#comment:67
<ul>
<li><strong>status</strong>
changed from <em>positive_review</em> to <em>needs_work</em>
</li>
</ul>
<p>
Hmm, I get an error here. This is on 5.1.beta6 with these patches only in addition.
</p>
<pre class="wiki">
$ ../../sage -t sage/symbolic/pynac.pyx
sage -t "devel/sage-main/sage/symbolic/pynac.pyx"
**********************************************************************
File "/Users/.../sage-5.1.beta6/devel/sage-main/sage/symbolic/pynac.pyx", line 544:
sage: get_sfunction_from_serial(i) == foo
Expected:
True
Got:
False
**********************************************************************
File "/Users/.../sage-5.1.beta6/devel/sage-main/sage/symbolic/pynac.pyx", line 546:
sage: py_latex_fderivative(i, (0, 1, 0, 1), (x, y^z))
Expected:
D[0, 1, 0, 1]func_with_args(x, y^z)
Got:
D[0, 1, 0, 1]\left({\rm foo}\right)\left(x, y^{z}\right)
**********************************************************************
1 items had failures:
2 of 19 in __main__.example_18
***Test Failed*** 2 failures.
For whitespace errors, see the file /Users/.../.sage//tmp/pynac_4902.py
[5.7 s]
----------------------------------------------------------------------
The following tests failed:
sage -t "devel/sage-main/sage/symbolic/pynac.pyx"
Total time for all tests: 5.7 seconds
</pre>
TicketkcrismanThu, 28 Jun 2012 17:32:21 GMT
https://trac.sagemath.org/ticket/11143#comment:68
https://trac.sagemath.org/ticket/11143#comment:68
<p>
I am not sure what is going on here. Testing this by hand works, testing it in the doctest doesn't. It's definitely the main patch that causes this.
</p>
<p>
I had a few semi-educated guesses, but they didn't seem to work. I'll keep digging.
</p>
TicketkcrismanThu, 28 Jun 2012 17:39:22 GMT
https://trac.sagemath.org/ticket/11143#comment:69
https://trac.sagemath.org/ticket/11143#comment:69
<blockquote class="citation">
<p>
Okay, I've reported the issue with Maxima using the wrong branch for <code>Shi</code> at <a class="ext-link" href="https://sourceforge.net/tracker/?func=detail&aid=3529992&group_id=4933&atid=104933"><span class="icon"></span>this bug tracker ticket</a>.
</p>
<pre class="wiki">(%i30) float(expintegral_shi(1/2));
(%o30) 3.141592653589793*%i+0.506996749819667
</pre></blockquote>
<p>
Incidentally, this is apparently now fixed. Is this something we should test for (not in this ticket) as well, since we use mpmath for it? I really hate how there is no link on the Maxima bugtracker as to the actual change in the code. Makes it harder for new folks to jump in.
</p>
TicketkcrismanThu, 28 Jun 2012 17:58:20 GMT
https://trac.sagemath.org/ticket/11143#comment:70
https://trac.sagemath.org/ticket/11143#comment:70
<p>
Aagh! It <em>was</em> what I originally thought - that we just have too many serials now. But I kept on testing the wrong occurrences of this code.
</p>
<p>
Patch coming up should fix this <em>and</em> at least postpone the agony the next time we add functions...
</p>
TicketkcrismanThu, 28 Jun 2012 18:02:17 GMTattachment set
https://trac.sagemath.org/ticket/11143
https://trac.sagemath.org/ticket/11143
<ul>
<li><strong>attachment</strong>
set to <em>trac_11143-pynac-serials.patch</em>
</li>
</ul>
TicketkcrismanThu, 28 Jun 2012 18:06:16 GMTstatus, description changed
https://trac.sagemath.org/ticket/11143#comment:71
https://trac.sagemath.org/ticket/11143#comment:71
<ul>
<li><strong>status</strong>
changed from <em>needs_work</em> to <em>positive_review</em>
</li>
<li><strong>description</strong>
modified (<a href="/ticket/11143?action=diff&version=71">diff</a>)
</li>
</ul>
<p>
Patchbot:
</p>
<p>
Apply to the Sage library:
</p>
<ol><li><a class="attachment" href="https://trac.sagemath.org/attachment/ticket/11143/trac_11143-v2.5-rebased.patch" title="Attachment 'trac_11143-v2.5-rebased.patch' in Ticket #11143">trac_11143-v2.5-rebased.patch</a><a class="trac-rawlink" href="https://trac.sagemath.org/raw-attachment/ticket/11143/trac_11143-v2.5-rebased.patch" title="Download"></a>
</li><li><a class="attachment" href="https://trac.sagemath.org/attachment/ticket/11143/trac-11143-ref.2.patch" title="Attachment 'trac-11143-ref.2.patch' in Ticket #11143">trac-11143-ref.2.patch</a><a class="trac-rawlink" href="https://trac.sagemath.org/raw-attachment/ticket/11143/trac-11143-ref.2.patch" title="Download"></a>
</li><li><a class="attachment" href="https://trac.sagemath.org/attachment/ticket/11143/trac_11143-pynac-serials.patch" title="Attachment 'trac_11143-pynac-serials.patch' in Ticket #11143">trac_11143-pynac-serials.patch</a><a class="trac-rawlink" href="https://trac.sagemath.org/raw-attachment/ticket/11143/trac_11143-pynac-serials.patch" title="Download"></a>
</li></ol><hr />
<p>
I feel like the latest patch is from an obscure enough piece of code that it could need review. On the other hand, it is a pretty trivial patch in other ways and only changes doctests. I'll put positive review for now, but feel free to change it back if you feel otherwise, Jeroen; I'm sure burcin or benjaminfjones would be able to sign off on it pretty quickly otherwise.
</p>
TicketbenjaminfjonesFri, 29 Jun 2012 02:30:12 GMT
https://trac.sagemath.org/ticket/11143#comment:72
https://trac.sagemath.org/ticket/11143#comment:72
<p>
The patch to the doctests in <code>sage/symbolic/pnyac.pyx</code> look (and tests) fine. I suspected it would be something like this, but didn't have the time earlier to track it down. Thanks!
</p>
TicketkcrismanFri, 29 Jun 2012 02:36:08 GMT
https://trac.sagemath.org/ticket/11143#comment:73
https://trac.sagemath.org/ticket/11143#comment:73
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/11143#comment:62" title="Comment 62">JoalHeagney</a>:
</p>
<blockquote class="citation">
<p>
With the patches applied to 5.0, my fractional integral code works on sine functions, but I still get the following error if pretty printing is on. Is there a trac post for this?
</p>
</blockquote>
<p>
Sorry not to get to this earlier, Joal. I have to admit that I haven't got a clue on this one yet, but don't have time to track it down quickly, since this is your own custom code thus far (though perhaps someday it might be useful for Sage?). Why don't you open a ticket for it, saying something about a pretty print error (as opposed to about fractional integrals). Then at least it has its own place, and you can document exactly what does and doesn't work.
</p>
TicketzimmermaFri, 29 Jun 2012 15:31:34 GMT
https://trac.sagemath.org/ticket/11143#comment:74
https://trac.sagemath.org/ticket/11143#comment:74
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/11143#comment:69" title="Comment 69">kcrisman</a>:
</p>
<pre class="wiki">> > (%i30) float(expintegral_shi(1/2));
> > (%o30) 3.141592653589793*%i+0.506996749819667
</pre><blockquote class="citation">
<p>
Is this something we should test for?
</p>
</blockquote>
<p>
yes please!
</p>
<p>
Paul
</p>
TicketkcrismanFri, 29 Jun 2012 15:45:04 GMT
https://trac.sagemath.org/ticket/11143#comment:75
https://trac.sagemath.org/ticket/11143#comment:75
<blockquote class="citation">
<pre class="wiki">> > (%i30) float(expintegral_shi(1/2));
> > (%o30) 3.141592653589793*%i+0.506996749819667
</pre><blockquote class="citation">
<p>
Is this something we should test for?
</p>
</blockquote>
<p>
yes please!
</p>
</blockquote>
<p>
Keep in mind this is a Maxima output, not one we currently can even easily access without using Maxima, since this ticket uses mpmath to evaluate these functions, and we don't (yet) have different algorithm parameters for all these special functions. We <em>do</em> test a fair number of values of the "Sage" versions of these functions in this ticket!
</p>
TicketvbraunSat, 30 Jun 2012 18:49:26 GMTstatus changed; dependencies set
https://trac.sagemath.org/ticket/11143#comment:76
https://trac.sagemath.org/ticket/11143#comment:76
<ul>
<li><strong>status</strong>
changed from <em>positive_review</em> to <em>needs_work</em>
</li>
<li><strong>dependencies</strong>
set to <em>#13109</em>
</li>
</ul>
<p>
Switching the deprecation to the new syntax.
</p>
TicketvbraunSat, 30 Jun 2012 19:02:47 GMTstatus, description, author changed
https://trac.sagemath.org/ticket/11143#comment:77
https://trac.sagemath.org/ticket/11143#comment:77
<ul>
<li><strong>status</strong>
changed from <em>needs_work</em> to <em>positive_review</em>
</li>
<li><strong>description</strong>
modified (<a href="/ticket/11143?action=diff&version=77">diff</a>)
</li>
<li><strong>author</strong>
changed from <em>Benjamin Jones</em> to <em>Benjamin Jones, Volker Braun</em>
</li>
</ul>
<p>
The new patch is just rediffed to apply on top of <a class="closed ticket" href="https://trac.sagemath.org/ticket/13109" title="enhancement: Rewrite deprecation to use trac ticket numbers (closed: fixed)">#13109</a>. Switching back to positive review.
</p>
TicketjdemeyerSun, 01 Jul 2012 18:51:44 GMTmilestone changed
https://trac.sagemath.org/ticket/11143#comment:78
https://trac.sagemath.org/ticket/11143#comment:78
<ul>
<li><strong>milestone</strong>
changed from <em>sage-5.2</em> to <em>sage-pending</em>
</li>
</ul>
TicketvbraunSun, 08 Jul 2012 11:35:08 GMTattachment set
https://trac.sagemath.org/ticket/11143
https://trac.sagemath.org/ticket/11143
<ul>
<li><strong>attachment</strong>
set to <em>trac_11143-v2.5-rebased.2.2.patch</em>
</li>
</ul>
<p>
Rediffed patch
</p>
TicketvbraunSun, 08 Jul 2012 11:37:08 GMT
https://trac.sagemath.org/ticket/11143#comment:79
https://trac.sagemath.org/ticket/11143#comment:79
<p>
The authors of <a class="closed ticket" href="https://trac.sagemath.org/ticket/11475" title="enhancement: improve prime_pi (speedup + small fixes) (closed: fixed)">#11475</a> thought its a good idea to remove trailing whitespace in random places, which broke this patch. Rediffed for sage-5.2.beta1.
</p>
TicketkcrismanThu, 19 Jul 2012 20:29:14 GMT
https://trac.sagemath.org/ticket/11143#comment:80
https://trac.sagemath.org/ticket/11143#comment:80
<p>
What is this pending? If <a class="closed ticket" href="https://trac.sagemath.org/ticket/11475" title="enhancement: improve prime_pi (speedup + small fixes) (closed: fixed)">#11475</a> has been unmerged, then is there an appropriate patch that can be merged in Sage 5.3, since 5.2.rc0 is out?
</p>
TicketkcrismanFri, 20 Jul 2012 02:11:10 GMTdescription changed
https://trac.sagemath.org/ticket/11143#comment:81
https://trac.sagemath.org/ticket/11143#comment:81
<ul>
<li><strong>description</strong>
modified (<a href="/ticket/11143?action=diff&version=81">diff</a>)
</li>
</ul>
<p>
AND the patchbot says it doesn't work. So there. Let's see if this works:
</p>
<p>
Apply to the Sage library:
</p>
<ol><li><a class="attachment" href="https://trac.sagemath.org/attachment/ticket/11143/trac_11143-v2.5-rebased.patch" title="Attachment 'trac_11143-v2.5-rebased.patch' in Ticket #11143">trac_11143-v2.5-rebased.patch</a><a class="trac-rawlink" href="https://trac.sagemath.org/raw-attachment/ticket/11143/trac_11143-v2.5-rebased.patch" title="Download"></a>
</li><li><a class="attachment" href="https://trac.sagemath.org/attachment/ticket/11143/trac-11143-ref.2.patch" title="Attachment 'trac-11143-ref.2.patch' in Ticket #11143">trac-11143-ref.2.patch</a><a class="trac-rawlink" href="https://trac.sagemath.org/raw-attachment/ticket/11143/trac-11143-ref.2.patch" title="Download"></a>
</li><li><a class="attachment" href="https://trac.sagemath.org/attachment/ticket/11143/trac_11143-pynac-serials.patch" title="Attachment 'trac_11143-pynac-serials.patch' in Ticket #11143">trac_11143-pynac-serials.patch</a><a class="trac-rawlink" href="https://trac.sagemath.org/raw-attachment/ticket/11143/trac_11143-pynac-serials.patch" title="Download"></a>
</li></ol>
TicketkcrismanFri, 20 Jul 2012 02:18:20 GMTmilestone changed
https://trac.sagemath.org/ticket/11143#comment:82
https://trac.sagemath.org/ticket/11143#comment:82
<ul>
<li><strong>milestone</strong>
changed from <em>sage-pending</em> to <em>sage-5.3</em>
</li>
</ul>
<p>
All tests in sage/calculus, sage/symbolic, and sage/functions pass against 5.2.beta1. If patchbot later says it's ok, then I think this is ok. Puttting to Sage 5.3.
</p>
TicketjdemeyerFri, 20 Jul 2012 06:41:06 GMT
https://trac.sagemath.org/ticket/11143#comment:83
https://trac.sagemath.org/ticket/11143#comment:83
<p>
It was put to sage-pending because of <a class="closed ticket" href="https://trac.sagemath.org/ticket/13109" title="enhancement: Rewrite deprecation to use trac ticket numbers (closed: fixed)">#13109</a> (which is now merged).
</p>
TicketkcrismanFri, 20 Jul 2012 12:00:14 GMT
https://trac.sagemath.org/ticket/11143#comment:84
https://trac.sagemath.org/ticket/11143#comment:84
<p>
Oh great. Unfortunately, Volker apparently replaced the patch based on <a class="closed ticket" href="https://trac.sagemath.org/ticket/13109" title="enhancement: Rewrite deprecation to use trac ticket numbers (closed: fixed)">#13109</a> with one based on <a class="closed ticket" href="https://trac.sagemath.org/ticket/11475" title="enhancement: improve prime_pi (speedup + small fixes) (closed: fixed)">#11475</a>, and the previous rebase was before <a class="closed ticket" href="https://trac.sagemath.org/ticket/13109" title="enhancement: Rewrite deprecation to use trac ticket numbers (closed: fixed)">#13109</a>, so I don't think there is any patch that would currently apply... this is silliness. I thought that <a class="closed ticket" href="https://trac.sagemath.org/ticket/13109" title="enhancement: Rewrite deprecation to use trac ticket numbers (closed: fixed)">#13109</a> had been delayed because of the sage-combinat issue, but apparently not?
</p>
TicketkcrismanFri, 27 Jul 2012 20:22:19 GMT
https://trac.sagemath.org/ticket/11143#comment:85
https://trac.sagemath.org/ticket/11143#comment:85
<p>
Hey Ben, question. Which <code>Li/li</code> is Maxima using with its conversion? I think that <code>expintegral_li</code> actually correspond to <code>Li</code> (<a class="closed ticket" href="https://trac.sagemath.org/ticket/3401" title="enhancement: Make Li symbolic and work with complex input (closed: fixed)">#3401</a>), not the <code>li</code> provided here, though the integral of <code>log_integral</code> does seem right... Also, while looking at this I noticed that
</p>
<pre class="wiki">\operatorname{li}(x) = \int_0^z \frac{dt}{\ln(t)} = \operatorname{Ei}(\ln(x))
</pre><p>
probably should have a <code>x</code> not a <code>z</code> in the integral bound.
</p>
TicketjdemeyerFri, 27 Jul 2012 20:31:08 GMTstatus changed
https://trac.sagemath.org/ticket/11143#comment:86
https://trac.sagemath.org/ticket/11143#comment:86
<ul>
<li><strong>status</strong>
changed from <em>positive_review</em> to <em>needs_work</em>
</li>
</ul>
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/11143#comment:84" title="Comment 84">kcrisman</a>:
</p>
<blockquote class="citation">
<p>
Oh great. Unfortunately, Volker apparently replaced the patch based on <a class="closed ticket" href="https://trac.sagemath.org/ticket/13109" title="enhancement: Rewrite deprecation to use trac ticket numbers (closed: fixed)">#13109</a> with one based on <a class="closed ticket" href="https://trac.sagemath.org/ticket/11475" title="enhancement: improve prime_pi (speedup + small fixes) (closed: fixed)">#11475</a>, and the previous rebase was before <a class="closed ticket" href="https://trac.sagemath.org/ticket/13109" title="enhancement: Rewrite deprecation to use trac ticket numbers (closed: fixed)">#13109</a>, so I don't think there is any patch that would currently apply...
</p>
</blockquote>
<p>
Indeed, this needs to be rebased to sage-5.2.rc1.
</p>
TicketvbraunSat, 28 Jul 2012 03:59:23 GMTattachment set
https://trac.sagemath.org/ticket/11143
https://trac.sagemath.org/ticket/11143
<ul>
<li><strong>attachment</strong>
set to <em>trac_11143-v2.5-rebased.2.patch</em>
</li>
</ul>
<p>
Rebased patch
</p>
TicketvbraunSat, 28 Jul 2012 04:00:53 GMTstatus, description changed
https://trac.sagemath.org/ticket/11143#comment:87
https://trac.sagemath.org/ticket/11143#comment:87
<ul>
<li><strong>status</strong>
changed from <em>needs_work</em> to <em>positive_review</em>
</li>
<li><strong>description</strong>
modified (<a href="/ticket/11143?action=diff&version=87">diff</a>)
</li>
</ul>
<p>
The rebased patch applies on sage-5.2.rc1. Switching this back to positive review
</p>
TicketjdemeyerWed, 01 Aug 2012 12:07:23 GMTstatus changed
https://trac.sagemath.org/ticket/11143#comment:88
https://trac.sagemath.org/ticket/11143#comment:88
<ul>
<li><strong>status</strong>
changed from <em>positive_review</em> to <em>needs_work</em>
</li>
</ul>
<p>
There is a trivial doctest failure on 32-bit i386 systems (possibly other systems too):
</p>
<pre class="wiki">sage -t --long -force_lib devel/sage/sage/functions/exp_integral.py
**********************************************************************
File "/var/lib/buildbot/build/sage/arando-1/arando_full/build/sage-5.3.beta1/devel/sage-main/sage/functions/exp_integral.py", line 1297:
sage: w = exponential_integral_1(2,4); w
Expected:
[0.04890051070806112, 0.0037793524098489067, 0.00036008245216265873, 3.7665622843924751e-05]
Got:
[0.04890051070806112, 0.0037793524098489067, 0.00036008245216265873, 3.766562284392475e-05]
**********************************************************************
</pre>
TicketbenjaminfjonesFri, 03 Aug 2012 05:20:07 GMTattachment set
https://trac.sagemath.org/ticket/11143
https://trac.sagemath.org/ticket/11143
<ul>
<li><strong>attachment</strong>
set to <em>trac_11143-v2.5-rebased.3.patch</em>
</li>
</ul>
<p>
fixed failing doctest
</p>
TicketbenjaminfjonesFri, 03 Aug 2012 05:22:54 GMTstatus, description changed
https://trac.sagemath.org/ticket/11143#comment:89
https://trac.sagemath.org/ticket/11143#comment:89
<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/11143?action=diff&version=89">diff</a>)
</li>
</ul>
<p>
Fixed the failing doctest (for the reviewer: this only changed lines 1300--1301 in <code>sage/functions/exp_integral.py</code>).
</p>
TicketjdemeyerFri, 10 Aug 2012 20:46:34 GMTstatus changed
https://trac.sagemath.org/ticket/11143#comment:90
https://trac.sagemath.org/ticket/11143#comment:90
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>needs_work</em>
</li>
</ul>
<p>
Wouldn't a <em>relative</em> tolerance be better than an absolute one? With the absolute tolerance, the fourth value can essentially be anything.
</p>
TicketbenjaminfjonesSat, 11 Aug 2012 02:08:57 GMT
https://trac.sagemath.org/ticket/11143#comment:91
https://trac.sagemath.org/ticket/11143#comment:91
<p>
Yes, you're right. I'll change that.
</p>
TicketbenjaminfjonesSat, 11 Aug 2012 03:34:29 GMTattachment set
https://trac.sagemath.org/ticket/11143
https://trac.sagemath.org/ticket/11143
<ul>
<li><strong>attachment</strong>
set to <em>trac_11143-v2.5-rebased.4.patch</em>
</li>
</ul>
<p>
changed <code>abs tol</code> to <code>rel tol</code>
</p>
TicketbenjaminfjonesSat, 11 Aug 2012 03:35:31 GMTstatus, description changed
https://trac.sagemath.org/ticket/11143#comment:92
https://trac.sagemath.org/ticket/11143#comment:92
<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/11143?action=diff&version=92">diff</a>)
</li>
</ul>
TicketbenjaminfjonesSun, 12 Aug 2012 23:31:13 GMT
https://trac.sagemath.org/ticket/11143#comment:93
https://trac.sagemath.org/ticket/11143#comment:93
<p>
Patchbot, please kindly apply:
</p>
<ul><li><a class="attachment" href="https://trac.sagemath.org/attachment/ticket/11143/trac_11143-v2.5-rebased.4.patch" title="Attachment 'trac_11143-v2.5-rebased.4.patch' in Ticket #11143">trac_11143-v2.5-rebased.4.patch</a><a class="trac-rawlink" href="https://trac.sagemath.org/raw-attachment/ticket/11143/trac_11143-v2.5-rebased.4.patch" title="Download"></a>
</li><li><a class="attachment" href="https://trac.sagemath.org/attachment/ticket/11143/trac-11143-ref.2.patch" title="Attachment 'trac-11143-ref.2.patch' in Ticket #11143">trac-11143-ref.2.patch</a><a class="trac-rawlink" href="https://trac.sagemath.org/raw-attachment/ticket/11143/trac-11143-ref.2.patch" title="Download"></a>
</li><li><a class="attachment" href="https://trac.sagemath.org/attachment/ticket/11143/trac_11143-pynac-serials.patch" title="Attachment 'trac_11143-pynac-serials.patch' in Ticket #11143">trac_11143-pynac-serials.patch</a><a class="trac-rawlink" href="https://trac.sagemath.org/raw-attachment/ticket/11143/trac_11143-pynac-serials.patch" title="Download"></a>
</li></ul><p>
to the Sage library.
</p>
<p>
Thank you in advance.
</p>
TicketjdemeyerMon, 13 Aug 2012 10:15:07 GMT
https://trac.sagemath.org/ticket/11143#comment:94
https://trac.sagemath.org/ticket/11143#comment:94
<p>
I'm happy with the changes to that line. I haven't re-checked the whole patch again, but I thrust that you didn't change anything else.
</p>
TicketjdemeyerMon, 13 Aug 2012 19:48:46 GMTstatus changed
https://trac.sagemath.org/ticket/11143#comment:95
https://trac.sagemath.org/ticket/11143#comment:95
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>positive_review</em>
</li>
</ul>
TicketjdemeyerTue, 14 Aug 2012 07:02:21 GMTstatus changed; resolution, merged set
https://trac.sagemath.org/ticket/11143#comment:96
https://trac.sagemath.org/ticket/11143#comment:96
<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.3.beta2</em>
</li>
</ul>
TicketkcrismanTue, 18 Jun 2013 17:38:51 GMT
https://trac.sagemath.org/ticket/11143#comment:97
https://trac.sagemath.org/ticket/11143#comment:97
<p>
See <a class="closed ticket" href="https://trac.sagemath.org/ticket/14766" title="defect: Fix Python int problem with exp_integral (closed: fixed)">#14766</a> for a followup.
</p>
Ticket