Sage: Ticket #11888: Sage is missing the lambert_w function conversion from Maxima
https://trac.sagemath.org/ticket/11888
<p>
Maxima returns solutions to some exponential equations in terms of the <code>lambert_w</code> function. Sage is missing a conversion for this function:
</p>
<pre class="wiki">
sage: solve(e^(5*x)+x==0, x, to_poly_solve=True)
[x == -1/5*lambert_w(5)]
sage: S = solve(e^(5*x)+x==0, x, to_poly_solve=True)
sage: z = S[0].rhs()
sage: z
-1/5*lambert_w(5)
sage: N(z)
---------------------------------------------------------------------------
TypeError 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/misc/functional.pyc in numerical_approx(x, prec, digits)
1264 prec = int((digits+1) * 3.32192) + 1
1265 try:
-> 1266 return x._numerical_approx(prec)
1267 except AttributeError:
1268 from sage.rings.complex_double import is_ComplexDoubleElement
/Users/jonesbe/sage/latest/local/lib/python2.6/site-packages/sage/symbolic/expression.so in sage.symbolic.expression.Expression._numerical_approx (sage/symbolic/expression.cpp:17950)()
TypeError: cannot evaluate symbolic expression numerically
sage: lambert_w(5)
---------------------------------------------------------------------------
NameError Traceback (most recent call last)
/Users/jonesbe/sage/sage-4.7.2.alpha2/devel/sage-test/sage/<ipython console> in <module>()
NameError: name 'lambert_w' is not defined
sage:
</pre><p>
<code>mpmath</code> can evaluate the <code>lambert_w</code> function, so it should be easy to add a new symbolic function to Sage that will fix this issue.
</p>
<hr />
<p>
Apply:
</p>
<ol><li><a class="attachment" href="https://trac.sagemath.org/attachment/ticket/11888/trac_11888.patch" title="Attachment 'trac_11888.patch' in Ticket #11888">trac_11888.patch</a><a class="trac-rawlink" href="https://trac.sagemath.org/raw-attachment/ticket/11888/trac_11888.patch" title="Download"></a> to <code>$SAGE_ROOT/devel/sage</code>
</li><li><a class="attachment" href="https://trac.sagemath.org/attachment/ticket/11888/trac_11888-doctests.patch" title="Attachment 'trac_11888-doctests.patch' in Ticket #11888">trac_11888-doctests.patch</a><a class="trac-rawlink" href="https://trac.sagemath.org/raw-attachment/ticket/11888/trac_11888-doctests.patch" title="Download"></a> to <code>$SAGE_ROOT/devel/sage</code>
</li></ol>en-usSagehttps://trac.sagemath.org/chrome/site/logo_sagemath_trac.png
https://trac.sagemath.org/ticket/11888
Trac 1.1.6kcrismanTue, 22 Nov 2011 01:46:53 GMTcc set
https://trac.sagemath.org/ticket/11888#comment:1
https://trac.sagemath.org/ticket/11888#comment:1
<ul>
<li><strong>cc</strong>
<em>kcrisman</em> added
</li>
</ul>
TicketbenjaminfjonesTue, 10 Jan 2012 02:41:53 GMTattachment set
https://trac.sagemath.org/ticket/11888
https://trac.sagemath.org/ticket/11888
<ul>
<li><strong>attachment</strong>
set to <em>trac_11888.patch</em>
</li>
</ul>
<p>
add lambert_w symbolic function
</p>
TicketbenjaminfjonesTue, 10 Jan 2012 02:44:56 GMTkeywords, status changed; author set
https://trac.sagemath.org/ticket/11888#comment:2
https://trac.sagemath.org/ticket/11888#comment:2
<ul>
<li><strong>keywords</strong>
<em>sd35.5</em> added
</li>
<li><strong>status</strong>
changed from <em>new</em> to <em>needs_review</em>
</li>
<li><strong>author</strong>
set to <em>Benjamin Jones</em>
</li>
</ul>
<p>
Preliminary patch needs review. The function has been added using the template developed as part of <a class="closed ticket" href="https://trac.sagemath.org/ticket/11143" title="defect: define symbolic functions for exponential integrals (closed: fixed)">#11143</a>. The issue described in the description is addressed in one of the doctests.
</p>
TicketkiniTue, 10 Jan 2012 11:37:20 GMTattachment set
https://trac.sagemath.org/ticket/11888
https://trac.sagemath.org/ticket/11888
<ul>
<li><strong>attachment</strong>
set to <em>trac_11888-doctests.patch</em>
</li>
</ul>
<p>
apply to $SAGE_ROOT/devel/sage
</p>
TicketkiniTue, 10 Jan 2012 11:39:21 GMTdescription changed
https://trac.sagemath.org/ticket/11888#comment:3
https://trac.sagemath.org/ticket/11888#comment:3
<ul>
<li><strong>description</strong>
modified (<a href="/ticket/11888?action=diff&version=3">diff</a>)
</li>
</ul>
<p>
Running <code>make ptestlong</code> now. I fixed a couple of doctests that broke, and fixed some typos and rST syntax problems in your docstring.
</p>
TicketkiniTue, 10 Jan 2012 12:12:58 GMT
https://trac.sagemath.org/ticket/11888#comment:4
https://trac.sagemath.org/ticket/11888#comment:4
<p>
All tests pass.
</p>
TicketktkohlTue, 10 Jan 2012 14:40:44 GMTcc changed
https://trac.sagemath.org/ticket/11888#comment:5
https://trac.sagemath.org/ticket/11888#comment:5
<ul>
<li><strong>cc</strong>
<em>ktkohl</em> added
</li>
</ul>
TicketbenjaminfjonesTue, 10 Jan 2012 20:05:47 GMT
https://trac.sagemath.org/ticket/11888#comment:6
https://trac.sagemath.org/ticket/11888#comment:6
<p>
Thanks for the fixes, kini. I've run <code>make ptestlong</code> with the patches applied and verified that all tests pass. Maybe I can get @kcrisman to finish a review this afternoon.
</p>
TicketkcrismanTue, 10 Jan 2012 20:24:20 GMT
https://trac.sagemath.org/ticket/11888#comment:7
https://trac.sagemath.org/ticket/11888#comment:7
<p>
I don't see any obvious problems, but the random expression usually doesn't change much with these new functions and this one is <em>really</em> different.
</p>
<p>
It's also spread across many lines, and I'm not sure if this is appropriate (just in this one case, of course).
</p>
TicketkiniWed, 11 Jan 2012 01:56:46 GMT
https://trac.sagemath.org/ticket/11888#comment:8
https://trac.sagemath.org/ticket/11888#comment:8
<p>
I spread it across lines because 1) I was trying to keep within the recommended PEP 8 guidelines for line length, and 2) because of this
</p>
<pre class="wiki">[2012-01-10 22:54:53] <kini> while I was fixing the second doctest, some weird
stuff started happening to vim
[2012-01-10 22:55:02] <kini> I thought my terminal had frozen or something
[2012-01-10 22:56:02] <kini> but it turns out that apparently opening a new line
after a line with a 1800-character-long Sage symbolic expression on it causes
vim to take a full 12 seconds to compute the correct indentation level for the
next line
[2012-01-10 22:56:20] <benjaminfjones> ha!
[2012-01-10 22:56:30] <kini> on a 4.5 GHz Core i5-2500K and utilizing three
cores!
[2012-01-10 22:56:39] <benjaminfjones> wow
</pre><p>
What is inappropriate about adding line breaks?
</p>
<p>
As for the length of the expression, it seems to be a fluke. With the patches applied, starting with random seeds other than <code>2</code> gives expressions of a more "normal" length.
</p>
TicketbenjaminfjonesWed, 11 Jan 2012 03:30:58 GMT
https://trac.sagemath.org/ticket/11888#comment:9
https://trac.sagemath.org/ticket/11888#comment:9
<p>
I agree, it looks like a fluke that the expression grows so large. I did some testing of <code>random_expr</code> and found that it "normally" produces output around 200 - 400 character long, but occasionally the outputs can be 10 times that (I saw a few around 2500 characters long!)
</p>
Ticketfredrik.johanssonWed, 11 Jan 2012 15:26:12 GMT
https://trac.sagemath.org/ticket/11888#comment:10
https://trac.sagemath.org/ticket/11888#comment:10
<p>
I strongly recommend implementing the general version of the Lambert W function (taking a branch parameter).
</p>
TicketkcrismanWed, 11 Jan 2012 15:43:34 GMT
https://trac.sagemath.org/ticket/11888#comment:11
https://trac.sagemath.org/ticket/11888#comment:11
<blockquote class="citation">
<p>
I strongly recommend implementing the general version of the Lambert W function (taking a branch parameter).
</p>
</blockquote>
<p>
Can you be more specific? (Is this standard with other multivalued functions in Sage?) Maybe this could be a separate ticket, unless the change was really easy.
</p>
TicketbenjaminfjonesWed, 11 Jan 2012 15:55:10 GMT
https://trac.sagemath.org/ticket/11888#comment:12
https://trac.sagemath.org/ticket/11888#comment:12
<p>
The change should be simple. mpmath implements the a branch <code>W_k(z)</code> for each integer <code>k</code>. It's just a matter of adding a second parameter to the wrapper and putting in some tests. I'm sitting on the train from Beverly MA to Logan airport now, I'll see if I can get it uploaded before the train stops (or my battery dies).
</p>
TicketkcrismanWed, 11 Jan 2012 15:57:58 GMT
https://trac.sagemath.org/ticket/11888#comment:13
https://trac.sagemath.org/ticket/11888#comment:13
<p>
Sweet, I didn't realize it was that quick. I love doing Sage development on that train :) There is also free wifi at Logan, I believe.
</p>
TicketkcrismanFri, 03 Feb 2012 03:23:33 GMT
https://trac.sagemath.org/ticket/11888#comment:14
https://trac.sagemath.org/ticket/11888#comment:14
<p>
Ping. I'd love to review this but sounds like Fredrik's point is good and if it's pretty easy for you to add that, we might as well.
</p>
Ticketfredrik.johanssonFri, 03 Feb 2012 10:14:29 GMT
https://trac.sagemath.org/ticket/11888#comment:15
https://trac.sagemath.org/ticket/11888#comment:15
<p>
Yes, it should be easy; just add an optional branch parameter, lambertw(z, branch=0).
</p>
<p>
Another suggestion is to use scipy.special.lambertw for evaluation over RDF and CDF. The SciPy implementation is a Cython translation of the double precision version in mpmath; it supports all branches and has excellent numerical stability, and runs quite a bit faster.
</p>
<pre class="wiki">import scipy.special
import mpmath
timeit("mpmath.lambertw(-35.0r+4.6jr,2r)")
timeit("mpmath.fp.lambertw(-35.0r+4.6jr,2r)")
timeit("scipy.special.lambertw(-35.0r+4.6jr,2r)")
print repr(complex(mpmath.lambertw(-35.0r+4.6jr,2r)))
print repr(mpmath.fp.lambertw(-35.0r+4.6jr,2r))
print repr(scipy.special.lambertw(-35.0r+4.6jr,2r))
625 loops, best of 3: 301 µs per loop
625 loops, best of 3: 65.1 µs per loop
625 loops, best of 3: 6.75 µs per loop
(0.91763023745202721+14.071606637742889j)
(0.91763023745202721+14.071606637742889j)
(0.91763023745202721+14.071606637742889j)
</pre>
TicketkcrismanFri, 03 Feb 2012 15:58:06 GMTstatus changed; reviewer, work_issues set
https://trac.sagemath.org/ticket/11888#comment:16
https://trac.sagemath.org/ticket/11888#comment:16
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>needs_work</em>
</li>
<li><strong>reviewer</strong>
set to <em>Keshav Kini, Karl-Dieter Crisman, Fredrik Johansson</em>
</li>
<li><strong>work_issues</strong>
set to <em>add second parameter, RDF/CDF stuff</em>
</li>
</ul>
<p>
Nice; I wonder if there are more places we are beginning to default to mpmath where SciPy could be useful for the double fields.
</p>
TicketbenjaminfjonesFri, 03 Feb 2012 17:25:29 GMT
https://trac.sagemath.org/ticket/11888#comment:17
https://trac.sagemath.org/ticket/11888#comment:17
<p>
Thanks for the ping. I'm still here (and I have a patch pretty much ready to go) I just got buried under teaching. I'll try to upload a patch this evening.
</p>
TicketbenjaminfjonesSat, 04 Feb 2012 01:10:01 GMT
https://trac.sagemath.org/ticket/11888#comment:18
https://trac.sagemath.org/ticket/11888#comment:18
<p>
After looking at this a bit more, it may be more involved than I initially envisioned to implement arbitrary branches of the lambert_w function in one symbolic function. Right now, the patch from SD 35.5 implements a subclass of `BuiltinFunction`. The underlying assumptions about subclasses of BuiltinFunction include: (from sage/symbolic/function.pyx)
</p>
<pre class="wiki">We assume that each subclass of this class will define one symbolic function.
</pre><p>
One issue is that there isn't a way (as far as I can see) to pass a branch parameter to `BuiltinFunction`'s <code>_call_</code> method. (Perhaps burcin or other authority on Sage symbolics can comment on this.)
</p>
<p>
Changing the evaluation numerical eval to use SciPy would be an easy change, that's for sure. I can do that quickly and upload a patch that implements the principle branch only.
</p>
<p>
Another idea I just had was to do something like what we have for the Bessel functions, in particular the `Bessel` class in sage/functions/special.py which is just a basic python class returning one of the Bessel (I,J,Y) functions of a given order.
</p>
TicketkcrismanSat, 04 Feb 2012 01:30:39 GMT
https://trac.sagemath.org/ticket/11888#comment:19
https://trac.sagemath.org/ticket/11888#comment:19
<p>
Ok, that makes sense. I feel like there should be a way to do that nonetheless - see <code>incomplete_gamma</code>, with
</p>
<pre class="wiki"> BuiltinFunction.__init__(self, "gamma", nargs=2, latex_name=r"\Gamma",
conversions={'maxima':'gamma_incomplete', 'mathematica':'Gamma',
'maple':'GAMMA'})
</pre><p>
and then use <code>_eval_</code> and <code>_evalf_</code>, but I don't have time to try looking into whether that would work here now.
</p>
<p>
Based on Fredrik's comment, make sure to only use SciPy for RDF/CDF - hopefully there is a good model elsewhere to use for that.
</p>
TicketbenjaminfjonesMon, 06 Feb 2012 05:24:03 GMTattachment set
https://trac.sagemath.org/ticket/11888
https://trac.sagemath.org/ticket/11888
<ul>
<li><strong>attachment</strong>
set to <em>trac_11888_v2.patch</em>
</li>
</ul>
<p>
proof of concept patch (not ready for review)
</p>
TicketbenjaminfjonesMon, 06 Feb 2012 05:26:29 GMT
https://trac.sagemath.org/ticket/11888#comment:20
https://trac.sagemath.org/ticket/11888#comment:20
<p>
OK, I made a second attempt. The patch isn't complete (I need to fix and add docstrings and do more testing) and is *not* ready for review, but if the reviewers will take a look at the basic implementation and give me feedback, I'd appreciate it.
</p>
<p>
In <a class="attachment" href="https://trac.sagemath.org/attachment/ticket/11888/trac_11888_v2.patch" title="Attachment 'trac_11888_v2.patch' in Ticket #11888">trac_11888_v2.patch</a><a class="trac-rawlink" href="https://trac.sagemath.org/raw-attachment/ticket/11888/trac_11888_v2.patch" title="Download"></a> there is a new symbolic function <code>lambert_w_branch</code> which takes two arguments, a complex number <code>z</code> and an integer branch <code>n</code>. This is implemented using scipy.special.lambertw for RDF/CDF arguments z and using mpmath otherwise.
</p>
<p>
There is also a wrapper function <code>lambert_w</code> that accepts either one or two arguments. For one argument it returns the principle branch <code>lambert_w_branch(z,0)</code>, for two it returns <code>lambert_w_branch(z,n)</code>. I still need to add the conversion from Maxima (by hand now, since <code>lambert_w</code> doesn't inherit from BuiltinFunction any more).
</p>
TicketbenjaminfjonesSat, 11 Feb 2012 22:07:49 GMTstatus changed; work_issues deleted
https://trac.sagemath.org/ticket/11888#comment:21
https://trac.sagemath.org/ticket/11888#comment:21
<ul>
<li><strong>status</strong>
changed from <em>needs_work</em> to <em>needs_review</em>
</li>
<li><strong>work_issues</strong>
<em>add second parameter, RDF/CDF stuff</em> deleted
</li>
</ul>
<p>
I fixed the doctests and added lambert_w to the symbol table. I verified that all tests pass including the random_tests.py ones. The patch <a class="attachment" href="https://trac.sagemath.org/attachment/ticket/11888/trac_11888_v3.patch" title="Attachment 'trac_11888_v3.patch' in Ticket #11888">trac_11888_v3.patch</a><a class="trac-rawlink" href="https://trac.sagemath.org/raw-attachment/ticket/11888/trac_11888_v3.patch" title="Download"></a> is ready for review.
</p>
TicketbenjaminfjonesSat, 11 Feb 2012 22:08:25 GMTdescription changed
https://trac.sagemath.org/ticket/11888#comment:22
https://trac.sagemath.org/ticket/11888#comment:22
<ul>
<li><strong>description</strong>
modified (<a href="/ticket/11888?action=diff&version=22">diff</a>)
</li>
</ul>
Ticketfredrik.johanssonSat, 11 Feb 2012 22:27:40 GMT
https://trac.sagemath.org/ticket/11888#comment:23
https://trac.sagemath.org/ticket/11888#comment:23
<p>
principle -> principal, branchs -> branches
</p>
<p>
Otherwise, from looking at the patch, seems good.
</p>
TicketbenjaminfjonesSun, 12 Feb 2012 00:28:46 GMT
https://trac.sagemath.org/ticket/11888#comment:24
https://trac.sagemath.org/ticket/11888#comment:24
<p>
Thanks for looking at the patch, Fredrik. I've fixed the mistakes and replaced the latest patch.
</p>
TicketbenjaminfjonesSun, 12 Feb 2012 00:29:15 GMTattachment set
https://trac.sagemath.org/ticket/11888
https://trac.sagemath.org/ticket/11888
<ul>
<li><strong>attachment</strong>
set to <em>trac_11888_v3.patch</em>
</li>
</ul>
<p>
adds lambert_w and lambert_w_branch functions
</p>
TicketkcrismanSun, 12 Feb 2012 03:45:44 GMT
https://trac.sagemath.org/ticket/11888#comment:25
https://trac.sagemath.org/ticket/11888#comment:25
<ul><li>typo
<pre class="wiki"> SciPy is used to evalute
</pre></li><li>Will this conflict with the beta function patch when it comes to the random test?
</li><li>I'm wondering whether we should add a couple conversions to <a class="missing wiki">Mma/Maple?</a> in the init (apparently Maxima is working fine, though see <a class="ext-link" href="http://www.ma.utexas.edu/pipermail/maxima/2011/025861.html"><span class="icon"></span>this possible enhancement</a>). Mathematica apparently calls it ProductLog...
</li></ul>
TicketbenjaminfjonesSun, 12 Feb 2012 06:48:48 GMT
https://trac.sagemath.org/ticket/11888#comment:26
https://trac.sagemath.org/ticket/11888#comment:26
<ul><li>I'll fix the typo (tomorrow)
</li><li>I'll make the beta function ticket a dependency so the random test will come out correctly after the two patches are merged in order
</li><li>ProductLog in Mathematica puts the branch parameter first. I guess it makes sense to be consistent with that convention as well as the discussion on the Maxima list. I can't figure out whether the generalized lambert function ever made it into Maxima..
</li></ul><p>
</p>
TicketbenjaminfjonesSun, 12 Feb 2012 20:49:15 GMTattachment set
https://trac.sagemath.org/ticket/11888
https://trac.sagemath.org/ticket/11888
<ul>
<li><strong>attachment</strong>
set to <em>trac_11888_v4.patch</em>
</li>
</ul>
<p>
addressed reviewer issues, changed order of arguments to be consistant with <a class="missing wiki">Mma/Maple?</a>
</p>
TicketbenjaminfjonesSun, 12 Feb 2012 20:49:38 GMTattachment set
https://trac.sagemath.org/ticket/11888
https://trac.sagemath.org/ticket/11888
<ul>
<li><strong>attachment</strong>
set to <em>trac_11888-random-tests.patch</em>
</li>
</ul>
<p>
fixes random tests after rebasing against <a class="closed ticket" href="https://trac.sagemath.org/ticket/9130" title="enhancement: Access to beta function (closed: fixed)">#9130</a>
</p>
TicketbenjaminfjonesSun, 12 Feb 2012 20:51:25 GMTdescription changed; dependencies set
https://trac.sagemath.org/ticket/11888#comment:27
https://trac.sagemath.org/ticket/11888#comment:27
<ul>
<li><strong>dependencies</strong>
set to <em>#9130</em>
</li>
<li><strong>description</strong>
modified (<a href="/ticket/11888?action=diff&version=27">diff</a>)
</li>
</ul>
TicketburcinMon, 13 Feb 2012 10:21:14 GMTreviewer, summary changed
https://trac.sagemath.org/ticket/11888#comment:28
https://trac.sagemath.org/ticket/11888#comment:28
<ul>
<li><strong>reviewer</strong>
changed from <em>Keshav Kini, Karl-Dieter Crisman, Fredrik Johansson</em> to <em>Keshav Kini, Karl-Dieter Crisman, Fredrik Johansson, Burcin Erocal</em>
</li>
<li><strong>summary</strong>
changed from <em>Sage is missing the lambert_w function conversion from Maxima</em> to <em>Sage is missing the lambert_w function</em>
</li>
</ul>
<p>
Do we really want to call this function <code>lambert_w_branch()</code>? Can we name it <code>lambert_w()</code>? I would even suggest to add custom printing methods (<code>_print_()</code> and <code>_print_latex_()</code>) to avoid printing the branch argument if it is 0.
</p>
<p>
If the function is named lambert_w, you can remove the wrapper function <code>lambert_w()</code> and the manual manipulation of the symbol table. In this case, a custom <code>__call__()</code> method would take the place of the wrapper method.
</p>
<p>
BTW, we should either open a new ticket to add known exact evaluations to <code>_eval_()</code> or do this here:
</p>
<ul><li>0 -> 0
</li><li>e -> 1
</li><li>-1/e -> -1
</li></ul>
TicketburcinMon, 13 Feb 2012 10:29:13 GMTstatus changed
https://trac.sagemath.org/ticket/11888#comment:29
https://trac.sagemath.org/ticket/11888#comment:29
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>needs_work</em>
</li>
</ul>
<p>
I have one more comment. Sorry for multiple emails.
</p>
<p>
You should check if the parent is <code>RDF</code> or <code>CDF</code> using <code>is</code>, not <code>==</code>. In this context, <code>parent</code> is an argument to the <code>_evalf_()</code> method, which overrides the <code>parent()</code> function imported from <code>sage.structure.coerce</code>. I suggest naming the argument <code>parent_d</code> instead of <code>parent</code>. Then you can do:
</p>
<pre class="wiki">R = parent_d or parent(z)
if R is float or R is complex or R is RDF or R is CDF:
import scipy.special
return scipy.special.lambertw(z, n)
else:
import mpmath
return mpmath_utils.call(mpmath.lambertw, z, n, parent=parent)
</pre>
TicketkcrismanMon, 13 Feb 2012 18:27:54 GMT
https://trac.sagemath.org/ticket/11888#comment:30
https://trac.sagemath.org/ticket/11888#comment:30
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/11888#comment:28" title="Comment 28">burcin</a>:
</p>
<blockquote class="citation">
<p>
Do we really want to call this function <code>lambert_w_branch()</code>? Can we name it <code>lambert_w()</code>? I would even suggest to add custom printing methods (<code>_print_()</code> and <code>_print_latex_()</code>) to avoid printing the branch argument if it is 0.
</p>
</blockquote>
<p>
That's a great idea.
</p>
TicketbenjaminfjonesSat, 18 Feb 2012 06:10:43 GMTdependencies changed
https://trac.sagemath.org/ticket/11888#comment:31
https://trac.sagemath.org/ticket/11888#comment:31
<ul>
<li><strong>dependencies</strong>
changed from <em>#9130</em> to <em>#12507</em>
</li>
</ul>
<p>
I've written a new patch that includes significant changes compared to the last one. I think I've included all of burcin's suggestions and I think it's much improved now. All tests pass with the patch applied on 5.0.beta4 + <a class="closed ticket" href="https://trac.sagemath.org/ticket/12507" title="task: Mark random symbolic expression doctests with #random (closed: fixed)">#12507</a>.
</p>
<p>
One thing I haven't managed to figure out is how to get integration to work, e.g.
</p>
<pre class="wiki">sage: integrate(lambert_w(x), x)
...
RuntimeError: ECL says: Error executing code in Maxima: lambert_w: wrong number of arguments.
</pre><p>
I guess that's because there isn't a two-argument version of lambert_w defined in maxima. The conversion maxima -> Sage works (as shown in one of the doctests) but it looks like the other way doesn't. Another example:
</p>
<pre class="wiki">sage: maxima(lambert_w(5))
Maxima ERROR:
lambert_w: wrong number of arguments.
-- an error. To debug this try: debugmode(true);
</pre><p>
Q: How do I get around this?
</p>
<p>
Numerical integration also fails unless I pass a lambda function:
</p>
<pre class="wiki">sage: numerical_integral(lambert_w(x), 0, 1)
Exception TypeError: "function not supported for these types, and can't coerce safely to supported types" in 'sage.gsl.integration.c_ff' ignored
...
(0.0, 0.0)
</pre><p>
but ....
</p>
<pre class="wiki">sage: numerical_integral(lambda x: lambert_w(x), 0, 1)
(0.33036612476168054, 3.667800782666048e-15)
</pre><p>
Q: How do I fix this?
</p>
TicketbenjaminfjonesSat, 18 Feb 2012 06:11:24 GMTattachment set
https://trac.sagemath.org/ticket/11888
https://trac.sagemath.org/ticket/11888
<ul>
<li><strong>attachment</strong>
set to <em>trac_11888_v5.patch</em>
</li>
</ul>
<p>
adds lambert_w function
</p>
TicketbenjaminfjonesSat, 18 Feb 2012 06:11:57 GMTdescription changed
https://trac.sagemath.org/ticket/11888#comment:32
https://trac.sagemath.org/ticket/11888#comment:32
<ul>
<li><strong>description</strong>
modified (<a href="/ticket/11888?action=diff&version=32">diff</a>)
</li>
</ul>
TicketburcinSat, 18 Feb 2012 16:39:51 GMT
https://trac.sagemath.org/ticket/11888#comment:33
https://trac.sagemath.org/ticket/11888#comment:33
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/11888#comment:31" title="Comment 31">benjaminfjones</a>:
</p>
<blockquote class="citation">
<p>
I've written a new patch that includes significant changes compared to the last one. I think I've included all of burcin's suggestions and I think it's much improved now. All tests pass with the patch applied on 5.0.beta4 + <a class="closed ticket" href="https://trac.sagemath.org/ticket/12507" title="task: Mark random symbolic expression doctests with #random (closed: fixed)">#12507</a>.
</p>
</blockquote>
<p>
Thanks! The patch looks really good. When checking if the input is 0 in <code>_eval_</code>, you might want to <code>return z</code> instead of <code>Integer(0)</code> to preserve the type of the input. Similarly, we should return <code>parent(z)(1)</code> or <code>parent(z)(-1)</code> in the other branches.
</p>
<p>
<snip>
</p>
<blockquote class="citation">
<p>
I guess that's because there isn't a two-argument version of lambert_w defined in maxima. The conversion maxima -> Sage works (as shown in one of the doctests) but it looks like the other way doesn't. Another example:
</p>
<pre class="wiki">sage: maxima(lambert_w(5))
Maxima ERROR:
lambert_w: wrong number of arguments.
-- an error. To debug this try: debugmode(true);
</pre><p>
Q: How do I get around this?
</p>
</blockquote>
<p>
You need to define <code>_maxima_init_evaled_()</code>. See line 895 of <code>sage/fuctions/other.py</code>:
</p>
<p>
<a class="ext-link" href="http://hg.sagemath.org/sage-main/file/c239be1054e0/sage/functions/other.py#l895"><span class="icon"></span>http://hg.sagemath.org/sage-main/file/c239be1054e0/sage/functions/other.py#l895</a>
</p>
TicketbenjaminfjonesWed, 22 Feb 2012 18:55:34 GMT
https://trac.sagemath.org/ticket/11888#comment:34
https://trac.sagemath.org/ticket/11888#comment:34
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/11888#comment:33" title="Comment 33">burcin</a>:
</p>
<blockquote class="citation">
<p>
You need to define <code>_maxima_init_evaled_()</code>. See line 895 of <code>sage/fuctions/other.py</code>:
</p>
<p>
<a class="ext-link" href="http://hg.sagemath.org/sage-main/file/c239be1054e0/sage/functions/other.py#l895"><span class="icon"></span>http://hg.sagemath.org/sage-main/file/c239be1054e0/sage/functions/other.py#l895</a>
</p>
</blockquote>
<p>
It seems that adding <code>_maxima_init_evaled_()</code> solves one issue, converting to Maxima with <code>_maxima_()</code>,
</p>
<pre class="wiki">sage: lambert_w(x)._maxima_()
lambert_w(x)
sage: lambert_w(1,x)._maxima_()
...
NotImplementedError: Non-principal branch lambert_w[1](x) is not implemented in Maxima
</pre><p>
but integration still doesn't work (same error is raised as before). Looking closer it seems that the issue is here:
</p>
<pre class="wiki">sage: z = lambert_w(x)
sage: z.operands()
[0, x]
sage: z.operator()
lambert_w
</pre><p>
because when <code>sr_to_max</code> is called in the integration code, I get:
</p>
<pre class="wiki">sage: from sage.interfaces.maxima_lib import sr_to_max
sage: sr_to_max(lambert_w(x))
<ECL: ((%LAMBERT_W) 0 $X)>
sage: sr_to_max(lambert_w(1, x))
<ECL: ((%LAMBERT_W) 1 $X)>
</pre><p>
and Maxima barfs because it doesn't know what to do with <code>((%LAMBERT_W) 0 $X)</code>.
</p>
TicketbenjaminfjonesTue, 13 Mar 2012 19:49:49 GMTattachment set
https://trac.sagemath.org/ticket/11888
https://trac.sagemath.org/ticket/11888
<ul>
<li><strong>attachment</strong>
set to <em>trac_11888_v6.patch</em>
</li>
</ul>
<p>
added custom latex printing and Maxima initialization
</p>
TicketbenjaminfjonesTue, 13 Mar 2012 21:08:50 GMTstatus changed
https://trac.sagemath.org/ticket/11888#comment:35
https://trac.sagemath.org/ticket/11888#comment:35
<ul>
<li><strong>status</strong>
changed from <em>needs_work</em> to <em>needs_review</em>
</li>
</ul>
<p>
I've posted my latest patch in case anyone wants to play around with getting integration of <code>lambert_w</code> to work.
</p>
<p>
This issue could be a new ticket. One solution I can see is to add <code>lambert_w</code> to the <code>special_sage_to_max</code> dictionary in <code>sage/intefaces/maxima_lib.py</code>. There are a few other special functions listed there (like <code>Ei</code> and <code>polylog</code>) that need special conversions to maxima.
</p>
<p>
So, I propose that we either:
</p>
<ol class="loweralpha"><li>Review patch <a class="attachment" href="https://trac.sagemath.org/attachment/ticket/11888/trac_11888_v6.patch" title="Attachment 'trac_11888_v6.patch' in Ticket #11888">trac_11888_v6.patch</a><a class="trac-rawlink" href="https://trac.sagemath.org/raw-attachment/ticket/11888/trac_11888_v6.patch" title="Download"></a> and open a new ticket for the integration issue
</li><li>Agree on a simple workaround like adding <code>lambert_w</code> to <code>special_sage_to_max</code> and I'll add it to the patch.
</li></ol>
TicketkcrismanWed, 14 Mar 2012 12:50:35 GMT
https://trac.sagemath.org/ticket/11888#comment:36
https://trac.sagemath.org/ticket/11888#comment:36
<p>
I think that b. makes sense. You'd also have to add <code>max_lambert_w</code> at about <a class="ext-link" href="http://hg.sagemath.org/sage-main/file/c239be1054e0/sage/interfaces/maxima_lib.py#l1093"><span class="icon"></span>this spot</a> but having numerical integrals would be worth it.
</p>
<p>
I assume that this is a pretty easy change? If not, I guess we could just document that this doesn't work yet. In either case something should be documented, though, since half of our bug reports seem to be people using new, cool functionality who then expect that new functionality to be fully featured as well - i.e., it's not really a bug report at all, but a feature request. Having good doc for what we <em>don't</em> do will help with that.
</p>
TicketkcrismanFri, 16 Mar 2012 02:12:04 GMTstatus changed
https://trac.sagemath.org/ticket/11888#comment:37
https://trac.sagemath.org/ticket/11888#comment:37
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>needs_work</em>
</li>
</ul>
<p>
'Needs work' for b.
</p>
TicketbenjaminfjonesMon, 19 Mar 2012 19:58:32 GMTstatus changed
https://trac.sagemath.org/ticket/11888#comment:38
https://trac.sagemath.org/ticket/11888#comment:38
<ul>
<li><strong>status</strong>
changed from <em>needs_work</em> to <em>needs_review</em>
</li>
</ul>
<p>
Success!
</p>
<p>
Symbolic and numerical integration now work as expected for the principle branch. I added doctests to indicate what is and is not implemented.
</p>
<hr />
<p>
One other comment, to indicate what causes errors, I want to add doctests to <code>lambert_w</code> such as:
</p>
<pre class="wiki">sage: integral(lambert_w(1,x), x)
ERROR: An unexpected error occurred while tokenizing input
...
RuntimeError: ECL says: Error executing code in Maxima: lambert_w: expected exactly 1 arguments.
</pre><p>
and
</p>
<pre class="wiki">sage: numerical_integral(lambert_w(x), 0, 1)
Exception TypeError: "function not supported for these types, and can't coerce safely to supported types" in 'sage.gsl.integration.c_ff' ignored
...
(0.0, 0.0)
</pre><p>
but the doctest framework doesn't recognize the <code>Exception TypeError</code> and it seems to automatically fail if a <code>RuntimeError</code> is raised. If I put the latter 4 lines in the docstring for <code>lambert_w</code>, it fails doctesting, the framework only sees the <code>(0.0, 0.0)</code> part at the end. Is there a way around either of these issues?
</p>
TicketbenjaminfjonesMon, 19 Mar 2012 19:59:05 GMTattachment set
https://trac.sagemath.org/ticket/11888
https://trac.sagemath.org/ticket/11888
<ul>
<li><strong>attachment</strong>
set to <em>trac_11888_v7.patch</em>
</li>
</ul>
<p>
adds lambert_w function, including integration
</p>
TicketbenjaminfjonesMon, 19 Mar 2012 20:00:20 GMTdescription changed
https://trac.sagemath.org/ticket/11888#comment:39
https://trac.sagemath.org/ticket/11888#comment:39
<ul>
<li><strong>description</strong>
modified (<a href="/ticket/11888?action=diff&version=39">diff</a>)
</li>
</ul>
TicketdavidloefflerMon, 26 Mar 2012 07:10:52 GMT
https://trac.sagemath.org/ticket/11888#comment:40
https://trac.sagemath.org/ticket/11888#comment:40
<p>
Apply trac_11888_v7.patch
</p>
<p>
(for patchbot, which is trying to apply all nine patches at once)
</p>
TicketbenjaminfjonesFri, 06 Apr 2012 18:45:28 GMTdescription changed
https://trac.sagemath.org/ticket/11888#comment:41
https://trac.sagemath.org/ticket/11888#comment:41
<ul>
<li><strong>description</strong>
modified (<a href="/ticket/11888?action=diff&version=41">diff</a>)
</li>
</ul>
TicketbenjaminfjonesSat, 07 Apr 2012 22:47:22 GMTdependencies deleted
https://trac.sagemath.org/ticket/11888#comment:42
https://trac.sagemath.org/ticket/11888#comment:42
<ul>
<li><strong>dependencies</strong>
<em>#12507</em> deleted
</li>
</ul>
<p>
I removed <a class="closed ticket" href="https://trac.sagemath.org/ticket/12507" title="task: Mark random symbolic expression doctests with #random (closed: fixed)">#12507</a> from dependencies since it was merged in 5.0.beta5 and now the patchbot is getting confused trying to apply <a class="closed ticket" href="https://trac.sagemath.org/ticket/12507" title="task: Mark random symbolic expression doctests with #random (closed: fixed)">#12507</a> to 5.0.beta12 before testing.
</p>
<p>
I verified that <a class="attachment" href="https://trac.sagemath.org/attachment/ticket/11888/trac_11888_v7.2.patch" title="Attachment 'trac_11888_v7.2.patch' in Ticket #11888">trac_11888_v7.2.patch</a><a class="trac-rawlink" href="https://trac.sagemath.org/raw-attachment/ticket/11888/trac_11888_v7.2.patch" title="Download"></a> applies cleanly to 5.0.beta12 and I'm rerunning a patchbot instance on it.
</p>
TicketkcrismanThu, 17 May 2012 12:28:01 GMT
https://trac.sagemath.org/ticket/11888#comment:43
https://trac.sagemath.org/ticket/11888#comment:43
<p>
I'm sure we can finish this off next week in Seattle. Meanwhile, an interesting update from the Maxima developers about coming attractions:
</p>
<pre class="wiki">
Message: 4
Date: Thu, 17 May 2012 04:31:13 +0000 (UTC)
From: Robert Dodier <robert.dodier@gmail.com>
To: maxima@math.utexas.edu
Subject: Re: [Maxima] Generalized Lambert W function - premature
commit
Message-ID: <jp1uuh$jv8$1@dough.gmane.org>
On 2012-05-17, David Billinghurst <dbmaxima@gmail.com> wrote:
> Oops. I have accidentally committed some code for Generalized Lambert
> W function to src/specfn.lisp. Still getting my head around git.
> The code seems functionally correct, and passes tests in
> tests/rtest_lambert_w.mac, but I hadn't finished polishing it and it
> is still undocumented. Unless anyone objects, I will leave it in
> place for the time being.
No problem, OK by me.
> There is a new function generalized_lambert_w(k,z) that returns the
> kth branch W_k(z). There are float and bigfloat routines for complex
> z. generalized_lambert_w(0,z) is not (yet) simplified to
> lambert_w(z), as I hadn't decided if this should be done
> unconditionally or controlled by a flag. Thoughts?
Is it more convenient to simplify W_0(z) instead of W(z) ? If not, then
it seems reasonable to just go ahead and simplify it.
If you decide against automatically simplifying W_0(z) to W(z), I guess
I hope you don't make it controlled by a flag; flags cause trouble,
because one can't guess by looking at some code how it's going to turn
out. How about a function to carry out the simplification.
</pre>
TicketbenjaminfjonesThu, 17 May 2012 20:37:24 GMT
https://trac.sagemath.org/ticket/11888#comment:44
https://trac.sagemath.org/ticket/11888#comment:44
<p>
That will be good; should allow us to integrate the non-principle branch. Although, in Sage 5.0, we're still a major version behind the current Maxima release.
</p>
TicketrbeezerFri, 18 May 2012 04:09:24 GMT
https://trac.sagemath.org/ticket/11888#comment:45
https://trac.sagemath.org/ticket/11888#comment:45
<p>
I am reviewing an expository paper about the Lambert W function and it says "Maple this" and "Maple that". Let's get this into Sage and stay competitive with the M's! ;-)
</p>
<p>
Rob, in cheerleader mode
</p>
TicketbenjaminfjonesFri, 18 May 2012 04:40:41 GMTattachment set
https://trac.sagemath.org/ticket/11888
https://trac.sagemath.org/ticket/11888
<ul>
<li><strong>attachment</strong>
set to <em>trac_11888_v7.2.patch</em>
</li>
</ul>
<p>
removed trailing whitespace
</p>
TicketbenjaminfjonesFri, 18 May 2012 04:41:27 GMT
https://trac.sagemath.org/ticket/11888#comment:46
https://trac.sagemath.org/ticket/11888#comment:46
<p>
I agree! In that spirit, here is a rebase of the patch for Sage-5.0.
</p>
TicketzimmermaFri, 25 May 2012 09:27:15 GMT
https://trac.sagemath.org/ticket/11888#comment:47
https://trac.sagemath.org/ticket/11888#comment:47
<p>
this ticket is pointed out on the SD40.5 wiki page. Is there any particular thing one should review?
</p>
<p>
Paul
</p>
TicketdsmFri, 25 May 2012 12:25:13 GMT
https://trac.sagemath.org/ticket/11888#comment:48
https://trac.sagemath.org/ticket/11888#comment:48
<p>
It looks like a few principle/principal mixups made it through.
</p>
TicketkcrismanFri, 25 May 2012 13:54:33 GMT
https://trac.sagemath.org/ticket/11888#comment:49
https://trac.sagemath.org/ticket/11888#comment:49
<blockquote class="citation">
<p>
this ticket is pointed out on the SD40.5 wiki page. Is there any particular thing one should review?
</p>
</blockquote>
<p>
I think that just checking everything still works and that syntax is proper (and spelling, thanks dsm) is good. Checking some random values against another program would be helpful, especially for the branches. Making sure documentation builds and looks good. But this has been looked at by a lot of eyes, so I don't think it needs to be gone over completely from scratch, especially since I think Ben has doctested a lot of the issues raised in previous comments (which are worth scanning).
</p>
TicketbenjaminfjonesFri, 25 May 2012 18:10:36 GMTkeywords changed
https://trac.sagemath.org/ticket/11888#comment:50
https://trac.sagemath.org/ticket/11888#comment:50
<ul>
<li><strong>keywords</strong>
<em>sd40.5</em> added
</li>
</ul>
TicketbenjaminfjonesFri, 25 May 2012 18:18:06 GMT
https://trac.sagemath.org/ticket/11888#comment:51
https://trac.sagemath.org/ticket/11888#comment:51
<p>
I can make a quick spelling fix patch, but I'll wait and see if anyone else has changes to suggest.
</p>
TicketdsmSat, 26 May 2012 07:14:33 GMT
https://trac.sagemath.org/ticket/11888#comment:52
https://trac.sagemath.org/ticket/11888#comment:52
<p>
After some real-world discussions, I'd prefer to avoid falling into Python ints for (some of) the special values:
</p>
<pre class="wiki">sage: parent(lambert_w(0))
Integer Ring
sage: parent(lambert_w(e))
<type 'int'>
sage: parent(lambert_w(-1/e))
<type 'int'>
sage: parent(lambert_w(SR(-1/e)))
<type 'int'>
sage: parent(lambert_w(SR(0)))
Integer Ring
</pre><p>
Mysteriously enough, instrumenting it reveals that <code>_eval_</code> is actually returning SR(1) which then in some part of the code I don't understand becomes int(1) before we get it back. If we explicitly return Integer(1) then it seems to stay as Integer(1). This isn't the biggest deal in the world but there have been several bug reports caused by something falling out of Sagespace into Pythonspace.
</p>
TicketdsmSat, 26 May 2012 20:45:08 GMT
https://trac.sagemath.org/ticket/11888#comment:53
https://trac.sagemath.org/ticket/11888#comment:53
<p>
It looks like whatever happens after _eval_ might "dereference" the SR; the call seems to give Integer(1) if _eval_ returns SR(Integer(1)). Probably someone who actually knows what's going on could explain it in one line.
</p>
TicketbenjaminfjonesSun, 27 May 2012 06:13:23 GMT
https://trac.sagemath.org/ticket/11888#comment:54
https://trac.sagemath.org/ticket/11888#comment:54
<p>
One solution is to change the return statements in these special cases where the automatic simplification returns an integer to just explicitly return <code>Integer(1)</code>, etc..
</p>
<p>
How does that sound?
</p>
TicketbenjaminfjonesSun, 27 May 2012 18:33:36 GMTdescription changed
https://trac.sagemath.org/ticket/11888#comment:55
https://trac.sagemath.org/ticket/11888#comment:55
<ul>
<li><strong>description</strong>
modified (<a href="/ticket/11888?action=diff&version=55">diff</a>)
</li>
</ul>
<p>
New patch is ready for review. I hope this can be the final revision!
</p>
<p>
Patchbot: apply <a class="attachment" href="https://trac.sagemath.org/attachment/ticket/11888/trac_11888_v8.patch" title="Attachment 'trac_11888_v8.patch' in Ticket #11888">trac_11888_v8.patch</a><a class="trac-rawlink" href="https://trac.sagemath.org/raw-attachment/ticket/11888/trac_11888_v8.patch" title="Download"></a> to $SAGE_ROOT/devel/sage
</p>
TicketdsmSun, 27 May 2012 20:02:40 GMT
https://trac.sagemath.org/ticket/11888#comment:56
https://trac.sagemath.org/ticket/11888#comment:56
<p>
Looking at it now.
</p>
TicketbenjaminfjonesSun, 27 May 2012 20:41:57 GMTattachment set
https://trac.sagemath.org/ticket/11888
https://trac.sagemath.org/ticket/11888
<ul>
<li><strong>attachment</strong>
set to <em>trac_11888_v8.patch</em>
</li>
</ul>
<p>
fixed spelling / grammer mistakes, returned parent(Integer(...)) for special values
</p>
TicketdsmSun, 27 May 2012 21:18:05 GMT
https://trac.sagemath.org/ticket/11888#comment:57
https://trac.sagemath.org/ticket/11888#comment:57
<p>
Okay, this looks good. Two copyedits, an extra doc describing the behaviours of the derivative function, some tests making sure we can't differentiate with respect to the branch number, and the addition of lambert_W(-pi/2) = pi/2*I as a special value.
</p>
<p>
I give positive review to the preexisting parts of v8; if the new bits of v9 look okay I think we're good to go.
</p>
TicketdsmSun, 27 May 2012 21:18:55 GMTattachment set
https://trac.sagemath.org/ticket/11888
https://trac.sagemath.org/ticket/11888
<ul>
<li><strong>attachment</strong>
set to <em>trac_11888_v9.patch</em>
</li>
</ul>
<p>
post-review version of lambertw sf
</p>
TicketbenjaminfjonesSun, 27 May 2012 22:06:36 GMT
https://trac.sagemath.org/ticket/11888#comment:58
https://trac.sagemath.org/ticket/11888#comment:58
<p>
New changes look good; good catch about the derivative w.r.t. branch. All relavent tests pass for me on sage-5.0. I would say this is ready to go in! Thanks for the very thorough review, Doug.
</p>
TicketdsmSun, 27 May 2012 22:09:50 GMTstatus, reviewer changed
https://trac.sagemath.org/ticket/11888#comment:59
https://trac.sagemath.org/ticket/11888#comment:59
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>positive_review</em>
</li>
<li><strong>reviewer</strong>
changed from <em>Keshav Kini, Karl-Dieter Crisman, Fredrik Johansson, Burcin Erocal</em> to <em>Keshav Kini, Karl-Dieter Crisman, Fredrik Johansson, Burcin Erocal, Douglas McNeil</em>
</li>
</ul>
TicketdsmSun, 27 May 2012 22:10:25 GMT
https://trac.sagemath.org/ticket/11888#comment:60
https://trac.sagemath.org/ticket/11888#comment:60
<p>
+1. Tx for the work!
</p>
TicketwasSun, 27 May 2012 22:18:39 GMTstatus, reviewer changed
https://trac.sagemath.org/ticket/11888#comment:61
https://trac.sagemath.org/ticket/11888#comment:61
<ul>
<li><strong>status</strong>
changed from <em>positive_review</em> to <em>needs_work</em>
</li>
<li><strong>reviewer</strong>
changed from <em>Keshav Kini, Karl-Dieter Crisman, Fredrik Johansson, Burcin Erocal, Douglas McNeil</em> to <em>Keshav Kini, Karl-Dieter Crisman, Fredrik Johansson, Burcin Erocal, Douglas McNeil, William Stein</em>
</li>
</ul>
<p>
This patch is awesome! It's also a great example of how to make a well-documented new symbolic function that illustrates many issues. Here are a few trivial nitpicks:
</p>
<ul><li>What is "simplication"?
<pre class="wiki">When automatic simplication occurs, the parent of the output value should be
</pre></li></ul><ul><li>This docstring should start with r" since it contains a backslash:
<pre class="wiki"> 646 """
647 The derivative of `W_n(x)` is `W_n(x)/(x \cdot W_n(x) + x)`.
</pre></li></ul><p>
(check for similar instances throughout).
</p>
<ul><li>Don't use periods at the end of exceptions (also don't capitalize). Many instances of this being wrong, e.g.,
<pre class="wiki"> 679 raise ValueError("Derivative not defined with respect to the branch number.")
</pre></li></ul><p>
Here's a good example of what an exception string should look like (built into python):
</p>
<pre class="wiki">>>> 1/0
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ZeroDivisionError: integer division or modulo by zero
</pre>
TicketdsmSun, 27 May 2012 22:33:54 GMT
https://trac.sagemath.org/ticket/11888#comment:62
https://trac.sagemath.org/ticket/11888#comment:62
<p>
Updated version taking into account comments of was.
</p>
TicketdsmSun, 27 May 2012 22:34:04 GMTstatus changed
https://trac.sagemath.org/ticket/11888#comment:63
https://trac.sagemath.org/ticket/11888#comment:63
<ul>
<li><strong>status</strong>
changed from <em>needs_work</em> to <em>needs_review</em>
</li>
</ul>
TicketdsmSun, 27 May 2012 22:46:34 GMTattachment set
https://trac.sagemath.org/ticket/11888
https://trac.sagemath.org/ticket/11888
<ul>
<li><strong>attachment</strong>
set to <em>trac_11888_v10.patch</em>
</li>
</ul>
<p>
minor edits
</p>
TicketwasSun, 27 May 2012 22:49:43 GMTstatus changed
https://trac.sagemath.org/ticket/11888#comment:64
https://trac.sagemath.org/ticket/11888#comment:64
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>positive_review</em>
</li>
</ul>
TicketjdemeyerThu, 14 Jun 2012 06:38:22 GMTstatus changed; resolution, merged set
https://trac.sagemath.org/ticket/11888#comment:65
https://trac.sagemath.org/ticket/11888#comment:65
<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.1.beta4</em>
</li>
</ul>
Ticket