Sage: Ticket #7377: Symbolic Ring to Maxima via EclObject
https://trac.sagemath.org/ticket/7377
<p>
With maxima-as-an-ecl-library and ecl accessible as a library, we can start interfacing with maxima via a binary library interface. This should be more efficient and more robust, because expressions can be transmitted in a much richer format than text and parsing does not have to recognise error messages and questions (since communication does not go via STDIN/STDOUT anymore)
</p>
<hr />
<p>
Status: All doctest failures (8 in total across 4 files) are due to the fact that Maxima asking a question now triggers a different error.
</p>
<hr />
<p>
Applies cleanly to 4.6.2.
</p>
<p>
This ticket is dependent on <a class="closed ticket" href="https://trac.sagemath.org/ticket/10766" title="defect: Update ECL to the latest upstream release. (closed: fixed)">#10766</a>, <a class="closed ticket" href="https://trac.sagemath.org/ticket/10773" title="enhancement: Update Maxima to the latest upstream release. (closed: fixed)">#10773</a>, <a class="closed ticket" href="https://trac.sagemath.org/ticket/10743" title="enhancement: Add iterator protocol to EclObject (closed: fixed)">#10743</a>. Ticket <a class="closed ticket" href="https://trac.sagemath.org/ticket/10818" title="defect: EclLib should allow signals to make LISP code interruptable (closed: fixed)">#10818</a> is desirable but not essential. Apply:
</p>
<pre class="wiki">trac_7377-abstract-maxima_p2.patch
trac_7377-maximalib_p2.patch
trac_7377-fastcalculus_p2.patch
trac_7377-better-ask-error_p2.patch
trac_7377-split_and_refactor-p2.patch
trac_7377-lazy-maxlib.p2.patch
trac_7377-floatcast.patch
trac_7377-unicode_to_ecl-p1.patch
</pre>en-usSagehttps://trac.sagemath.org/chrome/site/logo_sagemath_trac.png
https://trac.sagemath.org/ticket/7377
Trac 1.1.6nbruinTue, 03 Nov 2009 08:06:44 GMTattachment set
https://trac.sagemath.org/ticket/7377
https://trac.sagemath.org/ticket/7377
<ul>
<li><strong>attachment</strong>
set to <em>sagemax.py</em>
</li>
</ul>
<p>
example package for how to accomplish said interface
</p>
TicketnbruinTue, 03 Nov 2009 08:08:07 GMTowner changed
https://trac.sagemath.org/ticket/7377#comment:1
https://trac.sagemath.org/ticket/7377#comment:1
<ul>
<li><strong>owner</strong>
changed from <em>burcin</em> to <em>nbruin</em>
</li>
</ul>
TicketnbruinWed, 04 Nov 2009 17:00:14 GMT
https://trac.sagemath.org/ticket/7377#comment:2
https://trac.sagemath.org/ticket/7377#comment:2
<p>
I think the following email might be of interest to other people wanting to hack maxima:
</p>
<blockquote class="citation">
<p>
Since there is already a decent string parser for taking Sage stuff to
Maxima and (especially) getting back Sage stuff from Maxima, would
there be a way to modify the above - or ecl_eval - to give back the
Maxima expression directly? Perhaps this is already in the
lib/ecl.pyx file, though I didn't see it on the first reading.
</p>
</blockquote>
<p>
lib/ecl.pyx has nothing to do with maxima-specific stuff. That is all in
sagemax.py. It is actually a little bit important to keep that distinction.
Maxima is not the only lisp program we might want to interface with.
</p>
<p>
There is <code>max_read(S) = cadadr(EclObject("#$%s"%S))</code>, which *reads* the string
S as a maxima expression and returns its parsed result.
</p>
<p>
So <code>meval(max_read(S))</code> would do the trick. I do not know what routines maxima
has to convert expressions to a string. If I wanted to know, I would find it
out by looking at something like
</p>
<p>
<code>max_read("maxima-command-to-print-to-string(x)")</code>
</p>
<p>
and see what token the maxima reader puts in. I imagine you get something
like
</p>
<pre class="wiki"><ECL: ((MAX-PRINT-STRING) x)>
</pre><p>
back, So do:
</p>
<pre class="wiki">maxprint:=EclObject("MAX-PRINT-STRING") #do this once globally
meval(EclObject([[maxprint], maxexpression])).python()
</pre><p>
Indeed:
</p>
<pre class="wiki">sage: max_read("string(x)")
<ECL: (($STRING) $X)>
sage: meval(max_read("string(x)"))
<ECL: "x">
sage: meval(max_read("string(x)")).python()
'"x"'
sage: meval(max_read("string(x)")).python()[1:-1]
'x'
</pre><p>
So
</p>
<pre class="wiki">sage: maxprint=EclObject("$STRING")
sage: def max_to_string(s):
....: return meval(EclObject([[maxprint],s])).python()[1:-1]
</pre><p>
would give you a string representation. Be aware that #$...$ suffers from
performance loss, so if you repeatedly use it, your timings will go south
quickly. See Dodier's comments on this a while ago. Apparently you could
patch Maxima to lose the performance-losing routine (at the expense of
losing the wonderful linear-search history the maxima parser offers now).
</p>
<blockquote class="citation">
<p>
Sage command -> calls Maxima command -> Maxima command evaluated, but
in the ECL library version, not the pexpect version -> Maxima output
(a string) converted back using the stuff in Sage
</p>
</blockquote>
<p>
Yes, that would be an approach virtually orthogonal to the one taken in sagemax.py.
</p>
<pre class="wiki">> sage: str(ecl_eval("#$load(to_poly_solver)$"))
> append: argument must be a non-atomic expression; found false
> -- an error. To debug this try debugmode(true);
</pre><p>
To illustrate the inner workings:
</p>
<pre class="wiki">sage: from sagemax import *
sage: e=max_read('load("to_poly_solver")')
sage: e
<ECL: (($LOAD) "to_poly_solver")>
sage: meval(e)
append: argument must be a non-atomic expression; found false
-- an error. To debug this try debugmode(true);
sage: meval(max_read("append(a,b)"))
append: argument must be a non-atomic expression; found a
-- an error. To debug this try debugmode(true);
</pre><p>
So my guess is that "load" is trying to append to an improperly initialized
maxima list. I guess that means that in the current setting, our maxima
environment hasn't properly been set up yet. That is no surprise. It is
actually surprising that so much of maxima works without any initialization
at all.
</p>
TicketrobertwbSun, 17 Jan 2010 06:33:44 GMTattachment set
https://trac.sagemath.org/ticket/7377
https://trac.sagemath.org/ticket/7377
<ul>
<li><strong>attachment</strong>
set to <em>7377-abstract-maxima.patch</em>
</li>
</ul>
TicketnbruinSun, 17 Jan 2010 08:55:40 GMTupstream set
https://trac.sagemath.org/ticket/7377#comment:3
https://trac.sagemath.org/ticket/7377#comment:3
<ul>
<li><strong>upstream</strong>
set to <em>N/A</em>
</li>
</ul>
<p>
Finally success! Recipe for getting calculus use
maxima in ecl library mode do the following
</p>
<ul><li>apply the patch from <a class="closed ticket" href="https://trac.sagemath.org/ticket/6781" title="enhancement: Library access to ecl (closed: fixed)">#6781</a>
</li><li>apply Robert's 7377-abstract-maxima.patch
</li><li>apply maxlib.patch
</li></ul><p>
The calculus doctests currently fail because maxima asking questions does not get handled yet.
</p>
TicketnbruinMon, 18 Jan 2010 01:51:23 GMT
https://trac.sagemath.org/ticket/7377#comment:4
https://trac.sagemath.org/ticket/7377#comment:4
<p>
Updated maxlib.patch. Changes made:
</p>
<ul><li>Code catches (throw 'macsyma-quit) and tries to recognise errors (often successful)
</li><li>suppress questions and throw errors instead
</li><li>suppress ";;; load ..." lines and load warnings
</li><li>set environment appropriately for calculus instance
</li></ul><p>
There is a nasty problem that "forget(facts())" gets executed by sage, but throws errors. These get caught by the classic interface, but mess up the printing.
</p>
<p>
Doctesting calculus/calculus.py leads to 10 failures. All have to do with either forget() acting up or the fact that "maxima asks a question" gets reported differently by the two interfaces.
</p>
<p>
(the uploaded code has some diagnostic output in <code>maxima_eval</code> to try to debug the "forget" issues. The "ask" errors should just consist of updating the doctest.
</p>
<p>
Go at it!
</p>
TicketnbruinTue, 19 Jan 2010 09:04:46 GMTattachment set
https://trac.sagemath.org/ticket/7377
https://trac.sagemath.org/ticket/7377
<ul>
<li><strong>attachment</strong>
set to <em>maxlib.patch</em>
</li>
</ul>
<p>
Maxima via library; used by calculus
</p>
TicketnbruinTue, 19 Jan 2010 09:15:05 GMT
https://trac.sagemath.org/ticket/7377#comment:5
https://trac.sagemath.org/ticket/7377#comment:5
<p>
Another update:
</p>
<ul><li>change to symbolic/assumptions.py to not try: ... error: pass (gentler removal of assumptions makes the interface behave a bit better)
</li></ul><ul><li>monkey patch maxima to throw error on divergent integral instead of *printing* "Principal Value" and giving an answer.
</li></ul><p>
(maxima does behave as documented, so it is a matter of taste to change maxima's behaviour)
</p>
<ul><li>slightly more pretty/informative error messages
</li></ul><p>
Doctests failures on calculus.py are only 5 and are restricted to whitespace and differently formatted error messages (in other words, for real use, the two interfaces shouldn't be distinguishable anymore).
</p>
TicketburcinTue, 19 Jan 2010 22:59:47 GMTcc set
https://trac.sagemath.org/ticket/7377#comment:6
https://trac.sagemath.org/ticket/7377#comment:6
<ul>
<li><strong>cc</strong>
<em>burcin</em> added
</li>
</ul>
TicketkcrismanThu, 04 Feb 2010 14:09:37 GMT
https://trac.sagemath.org/ticket/7377#comment:7
https://trac.sagemath.org/ticket/7377#comment:7
<p>
Very sadly I do not have time right now to look at this properly, but if it behaves as advertised, the layout is very understandable and I think might even improve the previous interface in terms of future customization.
</p>
<p>
Do you think you can post some sample timings, just for information? After all, one (not the only) reason for this would be to significantly speed up repeated use of Maxima for certain applications.
</p>
<p>
Thanks to nbruin and robertwb for working so hard on this!
</p>
TicketnbruinTue, 09 Feb 2010 05:48:32 GMTattachment set
https://trac.sagemath.org/ticket/7377
https://trac.sagemath.org/ticket/7377
<ul>
<li><strong>attachment</strong>
set to <em>fastcalculus.patch</em>
</li>
</ul>
<p>
Patch to get faster calculus routines
</p>
TicketnbruinTue, 09 Feb 2010 06:05:29 GMT
https://trac.sagemath.org/ticket/7377#comment:8
https://trac.sagemath.org/ticket/7377#comment:8
<p>
The latest patch must be applied after <code>abstract-maxima</code> and <code>maxlib</code>. It adds routines <code>sr_to_max</code> and <code>max_to_sr</code> that try to translate between maxima's internal datastructure and SR while avoiding string transformations as much as possible. It falls back to the old interface to establish many of its symbol and operator translations, but takes note of them and uses a dictionary directly the next time around. It also avoids the overhead of binding expressions to maxima variables.
</p>
<p>
to go back and forth, <code>maxima_lib.MaximaElement()</code> as a new function {ecl()} which passes back the underlying <a class="missing wiki">EclObject?</a>. Conversely, <code>maxima_lib.maxima</code> accepts <a class="missing wiki">EclObjects?</a> and returns a corresponding expect interface object.
</p>
<p>
This patch also rewrite calculus integral, limit and sum to directly pass back and forth to maxima. There is a lot of overhead in SR itself, so speed gains are not that big. New times are:
</p>
<pre class="wiki">sage: timeit("integral(cos(x),x)")
625 loops, best of 3: 1.1 ms per loop
sage: timeit("integral(cos(x^2),x)")
5 loops, best of 3: 31.2 ms per loop
</pre><p>
where old were
</p>
<pre class="wiki">sage: timeit("integral(cos(x),x)")
25 loops, best of 3: 8.08 ms per loop
sage: timeit("integral(cos(x^2),x)")
5 loops, best of 3: 37 ms per loop
</pre><p>
It is easy to swap the old and new interfaces: simply comment/uncomment the appropriate lines in <code>calculus.py</code> to define the appropriate calculus.maxima
</p>
<p>
There are 7 doctest failures in <code>calculus.py</code>. All of them are whitespace, errors and changed precision in floats:
the binary interface passes <code>double</code>s directly, so there are no digits rounded. This affects some doctests. In other words, as far is <code>calculus.py</code> is concerned the two interfaces are functionally equivalent.
</p>
TicketsaliolaFri, 18 Jun 2010 13:11:42 GMTcc changed
https://trac.sagemath.org/ticket/7377#comment:9
https://trac.sagemath.org/ticket/7377#comment:9
<ul>
<li><strong>cc</strong>
<em>saliola</em> added
</li>
</ul>
TicketjpfloriMon, 15 Nov 2010 11:45:17 GMTcc changed
https://trac.sagemath.org/ticket/7377#comment:10
https://trac.sagemath.org/ticket/7377#comment:10
<ul>
<li><strong>cc</strong>
<em>jpflori</em> added
</li>
</ul>
TicketfbisseyTue, 16 Nov 2010 02:12:42 GMT
https://trac.sagemath.org/ticket/7377#comment:11
https://trac.sagemath.org/ticket/7377#comment:11
<p>
Does this need any rebasing? I am willing to give it a spin in sage-on-gentoo
to see if there are any obvious problems on linux.
</p>
TicketburcinTue, 16 Nov 2010 14:40:46 GMTstatus changed
https://trac.sagemath.org/ticket/7377#comment:12
https://trac.sagemath.org/ticket/7377#comment:12
<ul>
<li><strong>status</strong>
changed from <em>new</em> to <em>needs_work</em>
</li>
</ul>
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/7377#comment:11" title="Comment 11">fbissey</a>:
</p>
<blockquote class="citation">
<p>
Does this need any rebasing?
</p>
</blockquote>
<p>
Unfortunately, it does. Since Robert split off the Maxima pexpect interface, there were a few minor changes to <code>sage/interfaces/maxima.py</code>. His patch needs to be rebased.
</p>
<p>
AFAIR, the only reason that held this ticket back was a mix-up in the updates to the ecl/maxima packages. The version that properly built maxima as a library got lost since there were several new packages at the same time. I don't know if that problem is fixed in the latest release.
</p>
TicketdrkirkbyWed, 17 Nov 2010 11:47:53 GMT
https://trac.sagemath.org/ticket/7377#comment:13
https://trac.sagemath.org/ticket/7377#comment:13
<p>
Note that there's a ticket to update both Maxima and ECL open just now. See <a class="closed ticket" href="https://trac.sagemath.org/ticket/10187" title="defect: Update ECL to 10.4.1 and Maxima to 5.22.1 - currently the latest releases. (closed: fixed)">#10187</a>
</p>
<p>
At this point in time, it does not have positive review, but I think it is pretty close to getting it. The packages work together, but there's a doctest failure which needs to be resolved. As far as I can see, its just that Maxima is outputing results in a different form (yet again).
</p>
<p>
I would suggest you use the packages at <a class="closed ticket" href="https://trac.sagemath.org/ticket/10187" title="defect: Update ECL to 10.4.1 and Maxima to 5.22.1 - currently the latest releases. (closed: fixed)">#10187</a> and make this dependent on that, which I think will be merged in the next alpha.
</p>
TicketjpfloriMon, 24 Jan 2011 09:23:09 GMT
https://trac.sagemath.org/ticket/7377#comment:14
https://trac.sagemath.org/ticket/7377#comment:14
<p>
I tried to update the patches so that they apply on Sage 4.6.1 with Maxima 5.22.1, some things moved since the last patches were produced, but there was nothing too terrible. I'll up them right now.
</p>
<p>
However, there is now a problem when loading Maxima as a library. Maybe some changes in the spkg (in init-cl.lisp where set-pathnames is defined ?) are responsible for this. Without that line, there is a problem later.
</p>
<pre class="wiki">/home/jp/boulot/sage/sage-current/local/lib/python2.6/site-packages/sage/interfaces/maxima_lib.py in <module>()
487 ecl_eval("(defvar *MAXIMA-LANG-SUBDIR* NIL)")
488 ecl_eval("(set-locale-subdir)")
--> 489 ecl_eval("(set-pathnames)")
490 ecl_eval("(defun add-lineinfo (x) x)")
491 ecl_eval("""(defun retrieve (msg flag &aux (print? nil))(error (concatenate 'string "Maxima asks:" (meval (list '($string) msg)))))""")
/home/jp/boulot/sage/sage-current/local/lib/python2.6/site-packages/sage/libs/ecl.so in sage.libs.ecl.ecl_eval (sage/libs/ecl.c:5616)()
/home/jp/boulot/sage/sage-current/local/lib/python2.6/site-packages/sage/libs/ecl.so in sage.libs.ecl.ecl_eval (sage/libs/ecl.c:5570)()
/home/jp/boulot/sage/sage-current/local/lib/python2.6/site-packages/sage/libs/ecl.so in sage.libs.ecl.ecl_safe_eval (sage/libs/ecl.c:2403)()
RuntimeError: ECL says: In function PATHNAME, the value of the only argument is
NIL
which is not of the expected type (OR FILE-STREAM STRING PATHNAME)
Error importing ipy_profile_sage - perhaps you should run %upgrade?
WARNING: Loading of ipy_profile_sage failed.
</pre><p>
I don't know anything about Lisp, ECL and Maxima, so I was not able to fix that in the little time I tried.
</p>
<p>
As far as the patches as concerned, I feel that more work is needed. Deleting duplicate examples and methods, moving the library interface to libs directory, not sure where maxima abstract should go (if it is kept, should something be done like <a class="missing wiki">MaximaLib/Maxima?</a> as for Pari/GP ? no idea if those two "interfaces" share something...), getting rid of the inheritance on Expect in Maxima_lib and Maxima_abstract.
</p>
<p>
I'm ready to have a look at all of this, if someone helps me launching Maxima as library with latest versions of everything.
</p>
TicketjpfloriMon, 24 Jan 2011 09:25:24 GMTattachment set
https://trac.sagemath.org/ticket/7377
https://trac.sagemath.org/ticket/7377
<ul>
<li><strong>attachment</strong>
set to <em>trac_7377-abstract-maxima-rebased.patch</em>
</li>
</ul>
<p>
Rebased on Sage 4.6.1
</p>
TicketjpfloriMon, 24 Jan 2011 09:25:37 GMTattachment set
https://trac.sagemath.org/ticket/7377
https://trac.sagemath.org/ticket/7377
<ul>
<li><strong>attachment</strong>
set to <em>trac_7377-maximalib-rebased.patch</em>
</li>
</ul>
<p>
Rebased on Sage 4.6.1
</p>
TicketfbisseyMon, 24 Jan 2011 09:38:15 GMT
https://trac.sagemath.org/ticket/7377#comment:15
https://trac.sagemath.org/ticket/7377#comment:15
<p>
What happens if you just remove that line?
I just noticed a typo - marking makes you terrible at that kind of things :)
"We begin here by initializing maxima in library more"
</p>
<blockquote>
<p>
<sup>
</sup></p>
</blockquote>
TicketjpfloriMon, 24 Jan 2011 09:44:50 GMT
https://trac.sagemath.org/ticket/7377#comment:16
https://trac.sagemath.org/ticket/7377#comment:16
<p>
It fails later, here is the piece of code involved:
</p>
<pre class="wiki">/home/jp/boulot/sage/sage-current/local/lib/python2.6/site-packages/sage/interfaces/maxima_lib.py in __init__(self, script_subdirectory, logfile, server, init_code)
586 ecl_eval("(setf *standard-output* *dev-null*)")
587 for l in init_code:
--> 588 ecl_eval("#$%s$"%l)
589 ecl_eval("(setf *standard-output* original-standard-output)")
590
/home/jp/boulot/sage/sage-current/local/lib/python2.6/site-packages/sage/libs/ecl.so in sage.libs.ecl.ecl_eval (sage/libs/ecl.c:5616)()
/home/jp/boulot/sage/sage-current/local/lib/python2.6/site-packages/sage/libs/ecl.so in sage.libs.ecl.ecl_eval (sage/libs/ecl.c:5570)()
/home/jp/boulot/sage/sage-current/local/lib/python2.6/site-packages/sage/libs/ecl.so in sage.libs.ecl.ecl_safe_eval (sage/libs/ecl.c:2403)()
RuntimeError: ECL says: THROW: The catch MACSYMA-QUIT is undefined.
Error importing ipy_profile_sage - perhaps you should run %upgrade?
WARNING: Loading of ipy_profile_sage failed.
</pre><p>
Tried to google that, but couldn't find anything meaningful to me.
</p>
TicketfbisseyMon, 24 Jan 2011 09:59:33 GMT
https://trac.sagemath.org/ticket/7377#comment:17
https://trac.sagemath.org/ticket/7377#comment:17
<p>
me neither :(
</p>
TicketjpfloriMon, 24 Jan 2011 11:35:01 GMT
https://trac.sagemath.org/ticket/7377#comment:18
https://trac.sagemath.org/ticket/7377#comment:18
<p>
I don't know what happened but I rebuilt ecl and maxima while trying to add debug information and everything is fine now. I surely did something wrong at some point...
</p>
<p>
There are some problems left with what I uploaded earlier in sage.symbolic.integration.external I'll upload fixed version of the patches soon.
</p>
TicketjpfloriMon, 24 Jan 2011 11:39:35 GMTattachment set
https://trac.sagemath.org/ticket/7377
https://trac.sagemath.org/ticket/7377
<ul>
<li><strong>attachment</strong>
set to <em>trac_7377-fastcalculus-rebased.patch</em>
</li>
</ul>
<p>
Rebased on Sage 4.6.1, fixed changes in sage.symbolic.integration.external
</p>
TicketfbisseyTue, 25 Jan 2011 07:50:25 GMT
https://trac.sagemath.org/ticket/7377#comment:19
https://trac.sagemath.org/ticket/7377#comment:19
<p>
Ok I will give it a spin in sage-on-gentoo.
</p>
TicketfbisseyFri, 28 Jan 2011 03:28:50 GMT
https://trac.sagemath.org/ticket/7377#comment:20
https://trac.sagemath.org/ticket/7377#comment:20
<p>
I tried the patch against 4.6.2.alpha2 and it builds but it doesn't run properly
here:
</p>
<pre class="wiki">/usr/lib64/python2.6/site-packages/sage/calculus/calculus.py in <module>()
375 definite_integral
376 import sage.symbolic.pynac
--> 377 import sage.interfaces.maxima_lib
378
379 """
/usr/lib64/python2.6/site-packages/sage/interfaces/maxima_lib.py in <module>()
482 from sage.libs.ecl import *
483 ecl_eval("(setf *load-verbose* NIL)")
--> 484 ecl_eval("(require 'maxima)")
485 ecl_eval("(in-package :maxima)")
486 ecl_eval("(setq $nolabels t))")
/usr/lib64/python2.6/site-packages/sage/libs/ecl.so in sage.libs.ecl.ecl_eval (sage/libs/ecl.c:5617)()
992
993
--> 994
995
996
/usr/lib64/python2.6/site-packages/sage/libs/ecl.so in sage.libs.ecl.ecl_eval (sage/libs/ecl.c:5571)()
1007
1008
-> 1009
1010
1011
/usr/lib64/python2.6/site-packages/sage/libs/ecl.so in sage.libs.ecl.ecl_safe_eval (sage/libs/ecl.c:2404)()
184
185
--> 186
187
188
RuntimeError: ECL says: Module error: Don't know how to REQUIRE MAXIMA.
Error importing ipy_profile_sage - perhaps you should run %upgrade?
WARNING: Loading of ipy_profile_sage failed.
</pre><p>
I am currently also running ecl-11.1.1 which is a source of trouble but
I don't think it is responsible here.
</p>
TicketnbruinFri, 28 Jan 2011 05:43:27 GMT
https://trac.sagemath.org/ticket/7377#comment:21
https://trac.sagemath.org/ticket/7377#comment:21
<blockquote class="citation">
<p>
<a class="missing wiki">RuntimeError?</a>: ECL says: Module error: Don't know how to REQUIRE MAXIMA.
Error importing ipy_profile_sage - perhaps you should run %upgrade?
WARNING: Loading of ipy_profile_sage failed.
</p>
</blockquote>
<p>
My first guess is that maxima.fas is not available to your newly built ecl-11.1.1.
</p>
<p>
Note that in 4.6.1, building maxima produces this library:
</p>
<p>
$SAGE_ROOT/local/lib/ecl-10.4.1/maxima.fas
</p>
<p>
so once you upgrade ecl, you need to rebuild maxima as well. Did you do that?
</p>
TicketfbisseyFri, 28 Jan 2011 08:22:12 GMT
https://trac.sagemath.org/ticket/7377#comment:22
https://trac.sagemath.org/ticket/7377#comment:22
<p>
I downgraded to ecl-10.4.1 and rebuilt maxima and sage but I don't seem to have
maxima.fas, I have a number of other fas but not maxima.fas.
It was done on sage-on-gentoo, so it is possible that this particular file wasn't
installed for a reason or another.
I will check what the maxima spkg do.
</p>
TicketfbisseyFri, 28 Jan 2011 10:14:41 GMT
https://trac.sagemath.org/ticket/7377#comment:23
https://trac.sagemath.org/ticket/7377#comment:23
<p>
OK pity it is not build in maxima by default, works for me now.
Not sure how i will sell that one to the maintainer of maxima in Gentoo.
Even if I have a good relationship with him.
</p>
TicketjpfloriFri, 28 Jan 2011 10:33:38 GMT
https://trac.sagemath.org/ticket/7377#comment:24
https://trac.sagemath.org/ticket/7377#comment:24
<p>
I just upgraded to 4.6.2.aplha2 (hoping I won't have to rebuild from scratch for next upgrade...) and everything went fine, it gives me better timings than with the Pexpect interface. Before patches:
</p>
<pre class="wiki">Loading Sage library. Current Mercurial branch is: jp
sage: timeit("integral(cos(x^2),x)")
5 loops, best of 3: 96.6 ms per loop
sage:
Exiting Sage (CPU time 0m1.02s, Wall time 0m8.17s).
Exiting spawned Maxima process.
</pre><p>
After:
</p>
<pre class="wiki">Loading Sage library. Current Mercurial branch is: jp
sage: timeit("integral(cos(x^2),x)")
5 loops, best of 3: 62.8 ms per loop
sage:
Exiting Sage (CPU time 0m1.56s, Wall time 3m5.27s).
</pre><p>
However those are much more than what was posted above.
</p>
<p>
Glad to hear it also ran on Sage on Gentoo.
</p>
<p>
I think some refactoring still has to be done for the new classes. The abstract class is a good idea to transparently switch interface but I think it would be cleaner if it did not inherit from Expect class (and so "Maxima as a lib" does not too). I'll try to work on this this weekend.
</p>
<p>
It should be also be decided, which interface is used for what, especially since we can only have one "Maxima as a lib" running. Should that Maxima as lib be used for calculus and be given a direct access (maybe as "maximalib" variable as "maxima" gives access to a copy of Maxima in Sage, even if currently the "maxima" variable points to a different instance of Maxima than the one used by calculus).
</p>
TicketnbruinFri, 28 Jan 2011 19:23:03 GMT
https://trac.sagemath.org/ticket/7377#comment:25
https://trac.sagemath.org/ticket/7377#comment:25
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/7377#comment:24" title="Comment 24">jpflori</a>:
</p>
<p>
Hi Jean-Pierre,
</p>
<p>
It's great you're taking on this project! It has the potential of being a lot of fun. I won't be working on it, so I'm very happy to see someone else interested in taking it on. I'll give you some background on the points you raise, so that you can take more informed design decisions.
</p>
<blockquote class="citation">
<p>
I think some refactoring still has to be done for the new classes. The abstract class is a good idea to transparently switch interface but I think it would be cleaner if it did not inherit from Expect class (and so "Maxima as a lib" does not too). I'll try to work on this this weekend.
</p>
</blockquote>
<p>
The *only* reason to organize the maxima interfaces as they are now is because Robert remarked that whatever was needed to communicate with maxlib at a string-level was going to have a lot of overlap with the present maxima interface. Hence, he abstracted out the common stuff and I modified the concrete maxlib interface to talk to ecllib instead of a separate process. This was experimental and at the time I had no idea how much was necessary, so I changed as little as possible: The original interface inherited from expect, so the new one did too, just overriding whatever methods needed overriding. So yes, there will be a lot of lint and extraneous stuff in there. What you're looking at is a first hack.
</p>
<blockquote class="citation">
<p>
It should be also be decided, which interface is used for what, especially since we can only have one "Maxima as a lib" running. Should that Maxima as lib be used for calculus and be given a direct access (maybe as "maximalib" variable as "maxima" gives access to a copy of Maxima in Sage, even if currently the "maxima" variable points to a different instance of Maxima than the one used by calculus).
</p>
</blockquote>
<p>
The largest benefit is to be gained when the communication can avoid string parsing altogether. (ecllib at the moment converts Integers to ecl bignums via strings, which is silly: They are both implemented as gmp/mpir integers! The only reason is that I never succeeded in importing the gmp/mpir headers in a usable way in ecl.pyx, to copy over the integer. ECL largely avoids gmp's registered memory manager, so some care must be taken to transfer the integer to properly allocated memory.) The routines sr_to_max and max_to_sr (in the fastcalculus patch) implement this strategy. If you want to have this benefit, the maxlib instance *has* to be the "calculus" instance. Note that the default "maxima" instance is already distinct from the "calculus" instance:
</p>
<pre class="wiki">sage: integrate(cos(x),x);
sage: maxima(x);
sage:
Exiting Sage (CPU time 0m0.12s, Wall time 0m16.73s).
Exiting spawned Maxima process.
Exiting spawned Maxima process.
</pre><p>
(note the two maxima spawns)
</p>
<p>
Once the design has stabilized, it would be possible to make max_to_sr and sr_to_max more intelligent. For instance, SR variables would not need to be translated to maxima identifiers with the same name. This currently leads to problems, because this conversion collapses namespaces:
</p>
<pre class="wiki">sage: cosvar=SR.var("cos")
sage: cos(cosvar)
cos(cos)
sage: integrate(cos(cosvar),cosvar)
integrate(cos(cos), cos)
sage: cosvar=SR.var("sage_cos")
sage: integrate(cos(cosvar),cosvar)
sin(sage_cos)
</pre><p>
as you see, the print name of the SR.var matters!
</p>
<p>
Let me know if you have further questions. I might be able to help with information.
</p>
TicketkcrismanFri, 28 Jan 2011 19:35:30 GMT
https://trac.sagemath.org/ticket/7377#comment:26
https://trac.sagemath.org/ticket/7377#comment:26
<p>
Thanks so much, Nils and JP, for resurrecting this. JP, I stand ready to test anything you feel is ready to look at. If you know little about ECL, I know even less, so I can't do more than that, but this would be a great start to improving some of Sage's interface. It's true that the timing on average doesn't improve so greatly (yet), but the point is that not having to start Maxima up when you want to do an integral means more immediate gratification for the user. (Assuming immediate gratification is a good thing.)
</p>
TicketfbisseySat, 29 Jan 2011 03:22:44 GMT
https://trac.sagemath.org/ticket/7377#comment:27
https://trac.sagemath.org/ticket/7377#comment:27
<p>
Ok so it runs but in its present state it breaks quite a lot of doctests for me.
Unless you can point out something else I would need to do.
example 1
</p>
<pre class="wiki">sage -t -force_lib "devel/sage/sage/symbolic/function_factory.py"
**********************************************************************
File "/usr/share/sage/devel/sage/sage/symbolic/function_factory.py", line 174:
sage: g
Expected:
b*D[0](cr)(a)
Got:
b*del(a)
**********************************************************************
File "/usr/share/sage/devel/sage/sage/symbolic/function_factory.py", line 184:
sage: g.substitute_function(cr, cos)
Expected:
-b*sin(a)
Got:
b*del(a)
**********************************************************************
File "/usr/share/sage/devel/sage/sage/symbolic/function_factory.py", line 187:
sage: g.substitute_function(cr, (sin(x) + cos(x)).function(x))
Expected:
-(sin(a) - cos(a))*b
Got:
b*del(a)
**********************************************************************
1 items had failures:
3 of 58 in __main__.example_6
</pre><p>
example 2
</p>
<pre class="wiki">sage -t -force_lib "devel/sage/sage/interfaces/maxima.py"
**********************************************************************
File "/usr/share/sage/devel/sage/sage/interfaces/maxima.py", line 426:
sage: t.limit(Ax=0, dir='+')
Exception raised:
Traceback (most recent call last):
File "/usr/bin/ncadoctest.py", line 1231, in run_one_test
self.run_one_example(test, example, filename, compileflags)
File "/usr/bin/sagedoctest.py", line 38, in run_one_example
OrigDocTestRunner.run_one_example(self, test, example, filename, compileflags)
File "/usr/bin/ncadoctest.py", line 1172, in run_one_example
compileflags, 1) in test.globs
File "<doctest __main__.example_0[93]>", line 1, in <module>
t.limit(Ax=Integer(0), dir='+')###line 426:
sage: t.limit(Ax=0, dir='+')
File "expression.pyx", line 8202, in sage.symbolic.expression.Expression.limit (sage/symbolic/expression.cpp:31252)
File "/usr/lib/python2.6/site-packages/sage/calculus/calculus.py", line 1122, in limit
return l.sage()
File "element.pyx", line 327, in sage.structure.element.Element.__getattr__ (sage/structure/element.c:2715)
File "parent.pyx", line 277, in sage.structure.parent.getattr_from_other_class (sage/structure/parent.c:2841)
File "parent.pyx", line 175, in sage.structure.parent.raise_attribute_error (sage/structure/parent.c:2636)
AttributeError: 'sage.rings.integer.Integer' object has no attribute 'sage'
**********************************************************************
File "/usr/share/sage/devel/sage/sage/interfaces/maxima.py", line 894:
sage: f(3.2)
Expected:
-.05837414342758009
Got:
-.058374143427580086
**********************************************************************
File "/usr/share/sage/devel/sage/sage/interfaces/maxima.py", line 1006:
sage: maxima.version()
Expected:
'5.22.1'
Got:
'5.23.2'
**********************************************************************
File "/usr/share/sage/devel/sage/sage/interfaces/maxima.py", line 1087:
sage: maxima_version()
Expected:
'5.22.1'
Got:
'5.23.2'
**********************************************************************
File "/usr/share/sage/devel/sage/sage/interfaces/maxima.py", line 608:
sage: integrate(1/(x^3 *(a+b*x)^(1/3)),x)
Expected:
Traceback (most recent call last):
...
TypeError: Computation failed since Maxima requested additional constraints (try the command 'assume(a>0)' before integral or limit evaluation, for example):
Is a positive or negative?
Got:
Traceback (most recent call last):
File "/usr/bin/ncadoctest.py", line 1231, in run_one_test
self.run_one_example(test, example, filename, compileflags)
File "/usr/bin/sagedoctest.py", line 38, in run_one_example
OrigDocTestRunner.run_one_example(self, test, example, filename, compileflags)
File "/usr/bin/ncadoctest.py", line 1172, in run_one_example
compileflags, 1) in test.globs
File "<doctest __main__.example_6[3]>", line 1, in <module>
integrate(Integer(1)/(x**Integer(3) *(a+b*x)**(Integer(1)/Integer(3))),x)###line 608:
sage: integrate(1/(x^3 *(a+b*x)^(1/3)),x)
File "/usr/lib/python2.6/site-packages/sage/misc/functional.py", line 718, in integral
return x.integral(*args, **kwds)
File "expression.pyx", line 8153, in sage.symbolic.expression.Expression.integral (sage/symbolic/expression.cpp:30871)
File "/usr/lib/python2.6/site-packages/sage/symbolic/integration/integral.py", line 601, in integrate
return indefinite_integral(expression, v)
File "function.pyx", line 419, in sage.symbolic.function.Function.__call__ (sage/symbolic/function.cpp:4486)
File "/usr/lib/python2.6/site-packages/sage/symbolic/integration/integral.py", line 85, in _eval_
res = integrator(f, x)
File "/usr/lib/python2.6/site-packages/sage/symbolic/integration/external.py", line 19, in maxima_integrator
result = maxima.sr_integral(expression,v)
File "/usr/lib/python2.6/site-packages/sage/interfaces/maxima_lib.py", line 983, in sr_integral
raise error
RuntimeError: ECL says: Maxima asks:?mtext("Is ",a," positive or negative?")
**********************************************************************
File "/usr/share/sage/devel/sage/sage/interfaces/maxima.py", line 618:
sage: integral(x^n,x)
Expected:
Traceback (most recent call last):
...
TypeError: Computation failed since Maxima requested additional constraints (try the command 'assume(n+1>0)' before integral or limit evaluation, for example):
Is n+1 zero or nonzero?
Got:
Traceback (most recent call last):
File "/usr/bin/ncadoctest.py", line 1231, in run_one_test
self.run_one_example(test, example, filename, compileflags)
File "/usr/bin/sagedoctest.py", line 38, in run_one_example
OrigDocTestRunner.run_one_example(self, test, example, filename, compileflags)
File "/usr/bin/ncadoctest.py", line 1172, in run_one_example
compileflags, 1) in test.globs
File "<doctest __main__.example_6[7]>", line 1, in <module>
integral(x**n,x)###line 618:
sage: integral(x^n,x)
File "/usr/lib/python2.6/site-packages/sage/misc/functional.py", line 718, in integral
return x.integral(*args, **kwds)
File "expression.pyx", line 8153, in sage.symbolic.expression.Expression.integral (sage/symbolic/expression.cpp:30871)
File "/usr/lib/python2.6/site-packages/sage/symbolic/integration/integral.py", line 601, in integrate
return indefinite_integral(expression, v)
File "function.pyx", line 419, in sage.symbolic.function.Function.__call__ (sage/symbolic/function.cpp:4486)
File "/usr/lib/python2.6/site-packages/sage/symbolic/integration/integral.py", line 85, in _eval_
res = integrator(f, x)
File "/usr/lib/python2.6/site-packages/sage/symbolic/integration/external.py", line 19, in maxima_integrator
result = maxima.sr_integral(expression,v)
File "/usr/lib/python2.6/site-packages/sage/interfaces/maxima_lib.py", line 983, in sr_integral
raise error
RuntimeError: ECL says: Maxima asks:?mtext("Is ",n+1," zero or nonzero?")
**********************************************************************
5 items had failures:
1 of 95 in __main__.example_0
1 of 16 in __main__.example_13
1 of 3 in __main__.example_17
1 of 4 in __main__.example_21
2 of 11 in __main__.example_6
***Test Failed*** 6 failures.
For whitespace errors, see the file /home/francois/.sage/tmp/.doctest_maxima.py
</pre><p>
and there are more. Tests are still running on this slow machine.
</p>
TicketkcrismanSat, 29 Jan 2011 03:49:26 GMTauthor changed; reviewer set
https://trac.sagemath.org/ticket/7377#comment:28
https://trac.sagemath.org/ticket/7377#comment:28
<ul>
<li><strong>reviewer</strong>
set to <em>Jean-Pierre Flori, Francois Bissey, Karl-Dieter Crisan</em>
</li>
<li><strong>author</strong>
changed from <em>Nils Bruin</em> to <em>Nils Bruin, Jean-Pierre Flori</em>
</li>
</ul>
<blockquote class="citation">
<pre class="wiki">sage -t -force_lib "devel/sage/sage/symbolic/function_factory.py"
**********************************************************************
File "/usr/share/sage/devel/sage/sage/symbolic/function_factory.py", line 174:
sage: g
Expected:
b*D[0](cr)(a)
Got:
b*del(a)
**********************************************************************
File "/usr/share/sage/devel/sage/sage/symbolic/function_factory.py", line 184:
sage: g.substitute_function(cr, cos)
Expected:
-b*sin(a)
Got:
b*del(a)
**********************************************************************
File "/usr/share/sage/devel/sage/sage/symbolic/function_factory.py", line 187:
sage: g.substitute_function(cr, (sin(x) + cos(x)).function(x))
Expected:
-(sin(a) - cos(a))*b
Got:
b*del(a)
**********************************************************************
</pre></blockquote>
<p>
Hmm, that is very interesting. I am not quite sure what this <code>del</code> thing is, but I remember seeing something about it on the Maxima list...
</p>
<blockquote class="citation">
<p>
File "/usr/share/sage/devel/sage/sage/interfaces/maxima.py", line 426:
</p>
<blockquote>
<p>
sage: t.limit(Ax=0, dir='+')
</p>
<blockquote>
<p>
return l.sage()
</p>
</blockquote>
<p>
File "element.pyx", line 327, in sage.structure.element.Element.<span class="underline">getattr</span> (sage/structure/element.c:2715)
File "parent.pyx", line 277, in sage.structure.parent.getattr_from_other_class (sage/structure/parent.c:2841)
File "parent.pyx", line 175, in sage.structure.parent.raise_attribute_error (sage/structure/parent.c:2636)
</p>
</blockquote>
<blockquote>
<p>
<a class="missing wiki">AttributeError?</a>: 'sage.rings.integer.Integer' object has no attribute 'sage'
</p>
</blockquote>
</blockquote>
<p>
This must be us using Sage Integers somehow at the library level where before they were coming back from Maxima?
</p>
<blockquote class="citation">
<p>
<strong></strong><strong></strong><strong></strong><strong></strong><strong></strong><strong></strong><strong></strong><strong></strong><strong></strong><strong></strong><strong></strong><strong></strong><strong></strong><strong></strong><strong></strong><strong></strong><strong></strong><strong>
File "/usr/share/sage/devel/sage/sage/interfaces/maxima.py", line 608:
</strong></p>
<blockquote>
<p>
sage: integrate(1/(x<sup>3 *(a+b*x)</sup>(1/3)),x)
</p>
</blockquote>
<p>
Expected:
</p>
<blockquote>
<p>
Traceback (most recent call last):
...
<a class="missing wiki">TypeError?</a>: Computation failed since Maxima requested additional constraints (try the command 'assume(a>0)' before integral or limit evaluation, for example):
Is a positive or negative?
</p>
</blockquote>
</blockquote>
<p>
Notice we expect a <a class="missing wiki">TypeError?</a>.
</p>
<blockquote class="citation">
<blockquote>
<p>
<a class="missing wiki">RuntimeError?</a>: ECL says: Maxima asks:?mtext("Is ",a," positive or negative?")
</p>
</blockquote>
</blockquote>
<p>
Now we just get a different error. I assume that the new code interface has something about ECL asking. We would want to make sure that this still is turned into the helpful type of message we have here, but that should be easy (if tedious) to make work.
</p>
<p>
Thank you for beginning this testing!
</p>
TicketkcrismanSat, 29 Jan 2011 03:50:00 GMTreviewer changed
https://trac.sagemath.org/ticket/7377#comment:29
https://trac.sagemath.org/ticket/7377#comment:29
<ul>
<li><strong>reviewer</strong>
changed from <em>Jean-Pierre Flori, Francois Bissey, Karl-Dieter Crisan</em> to <em>Jean-Pierre Flori, Francois Bissey, Karl-Dieter Crisman</em>
</li>
</ul>
<p>
I don't have the cedille, pardon me :(
</p>
TicketfbisseySat, 29 Jan 2011 03:58:12 GMTreviewer changed
https://trac.sagemath.org/ticket/7377#comment:30
https://trac.sagemath.org/ticket/7377#comment:30
<ul>
<li><strong>reviewer</strong>
changed from <em>Jean-Pierre Flori, Francois Bissey, Karl-Dieter Crisman</em> to <em>Jean-Pierre Flori, François Bissey, Karl-Dieter Crisman</em>
</li>
</ul>
<p>
I have a cedilla thanks to the international setting on my desktop.
</p>
<p>
More seriously, it should be pointed out that this is done with ecl-11.1.1
and it may have an influence. I have a faster machine at work and I'll test
ecl-10.4.1 on Monday.
</p>
TicketfbisseySat, 29 Jan 2011 07:59:59 GMT
https://trac.sagemath.org/ticket/7377#comment:31
https://trac.sagemath.org/ticket/7377#comment:31
<p>
Ok so I have a lot of failures that I attribute to maxima-lib, I am making a list
for quick reference. I have another sage-on-gentoo report on there being a lot failure with it and this time with ecl-10.4.1.
</p>
<blockquote>
<p>
sage -t -force_lib "devel/sage/sage/functions/special.py" # Time out<br />
sage -t -force_lib "devel/sage/sage/functions/piecewise.py"<br />
sage -t -force_lib "devel/sage/sage/functions/min_max.py"<br />
sage -t -force_lib "devel/sage/sage/functions/orthogonal_polys.py"<br />
sage -t -force_lib "devel/sage/sage/interfaces/maxima_lib.py"<br />
sage -t -force_lib "devel/sage/sage/interfaces/maxima_abstract.py"<br />
sage -t -force_lib "devel/sage/sage/interfaces/maxima.py"<br />
sage -t -force_lib "devel/sage/sage/symbolic/function_factory.py"<br />
sage -t -force_lib "devel/sage/sage/symbolic/integration/integral.py" # Time out<br />
sage -t -force_lib "devel/sage/sage/symbolic/integration/external.py"<br />
sage -t -force_lib "devel/sage/sage/symbolic/relation.py" # Time out<br />
sage -t -force_lib "devel/sage/sage/symbolic/assumptions.py" # Time out<br />
sage -t -force_lib "devel/sage/sage/symbolic/power_helper.pyx"<br />
sage -t -force_lib "devel/sage/sage/symbolic/expression_conversions.py"<br />
sage -t -force_lib "devel/sage/sage/symbolic/ring.pyx"<br />
sage -t -force_lib "devel/sage/sage/symbolic/expression.pyx" # Time out<br />
sage -t -force_lib "devel/sage/sage/rings/number_field/number_field_element_quadratic.pyx"<br />
sage -t -force_lib "devel/sage/sage/rings/number_field/number_field_element.pyx"<br />
sage -t -force_lib "devel/sage/sage/structure/sage_object.pyx"<br />
sage -t -force_lib "devel/sage/sage/misc/functional.py"<br />
sage -t -force_lib "devel/sage/sage/modules/free_module_element.pyx"<br />
sage -t -force_lib "devel/sage/sage/modular/modform/ambient_R.py"<br />
sage -t -force_lib "devel/sage/sage/calculus/desolvers.py"<br />
sage -t -force_lib "devel/sage/sage/calculus/calculus.py"<br />
sage -t -force_lib "devel/sage/sage/calculus/tests.py"<br />
sage -t -force_lib "devel/sage/sage/calculus/functional.py"<br />
sage -t -force_lib "devel/sage/sage/calculus/interpolators.pyx"<br />
sage -t -force_lib "devel/sage/sage/calculus/wester.py"<br />
</p>
</blockquote>
<p>
Some are probably due to ecl-11.1.1 so it should shrink, but it will take a bit
of time since ecl, maxima and sage have to be rebuild.
</p>
TicketfbisseySat, 29 Jan 2011 10:10:33 GMT
https://trac.sagemath.org/ticket/7377#comment:32
https://trac.sagemath.org/ticket/7377#comment:32
<p>
ecl-10.4.1, maxima-5.23.2:<br />
sage -t --verbose -force_lib "devel/sage/sage/functions/special.py" times out because it stops:
</p>
<pre class="wiki">Trying:
elliptic_e(arccoth(Integer(1)), x**Integer(2)*e)###line 535:_sage_ >>> elliptic_e(arccoth(1), x^2*e)
Expecting:
elliptic_e(arccoth(1), x^2*e)
The number 1 isn't in the domain of acoth
-- an error. To debug this try: debugmode(true);
Error in format: Unknown format directive.
The number ~:M isn't in the domain of ~A
^
while processing indirect format string:
~?
^
No restarts available.
Broken at LAMBDA.
MAXIMA>>
</pre>
TicketfbisseySat, 29 Jan 2011 10:56:25 GMT
https://trac.sagemath.org/ticket/7377#comment:33
https://trac.sagemath.org/ticket/7377#comment:33
<p>
Interesting one, notice that it still wants maxima-5.19.1
</p>
<pre class="wiki">sage -t -force_lib "devel/sage/sage/interfaces/maxima_lib.py"
**********************************************************************
File "/usr/share/sage/devel/sage/sage/interfaces/maxima_lib.py", line 426:
sage: t.limit(Ax=0,dir='above')
Exception raised:
Traceback (most recent call last):
File "/usr/bin/ncadoctest.py", line 1231, in run_one_test
self.run_one_example(test, example, filename, compileflags)
File "/usr/bin/sagedoctest.py", line 38, in run_one_example
OrigDocTestRunner.run_one_example(self, test, example, filename, compileflags)
File "/usr/bin/ncadoctest.py", line 1172, in run_one_example
compileflags, 1) in test.globs
File "<doctest __main__.example_0[93]>", line 1, in <module>
t.limit(Ax=Integer(0),dir='above')###line 426:
sage: t.limit(Ax=0,dir='above')
File "expression.pyx", line 8202, in sage.symbolic.expression.Expression.limit (sage/symbolic/expression.cpp:31252)
File "/usr/lib/python2.6/site-packages/sage/calculus/calculus.py", line 1122, in limit
return l.sage()
File "element.pyx", line 327, in sage.structure.element.Element.__getattr__ (sage/structure/element.c:2715)
File "parent.pyx", line 277, in sage.structure.parent.getattr_from_other_class (sage/structure/parent.c:2841)
File "parent.pyx", line 175, in sage.structure.parent.raise_attribute_error (sage/structure/parent.c:2636)
AttributeError: 'sage.rings.integer.Integer' object has no attribute 'sage'
**********************************************************************
File "/usr/share/sage/devel/sage/sage/interfaces/maxima_lib.py", line 966:
sage: maxima.version()
Expected:
'5.19.1'
Got:
'5.23.2'
**********************************************************************
File "/usr/share/sage/devel/sage/sage/interfaces/maxima_lib.py", line 1076:
sage: maxima_version()
Expected:
'5.19.1'
Got:
'5.23.2'
**********************************************************************
File "/usr/share/sage/devel/sage/sage/interfaces/maxima_lib.py", line 639:
sage: integrate(1/(x^3 *(a+b*x)^(1/3)),x)
Expected:
Traceback (most recent call last):
...
TypeError: Computation failed since Maxima requested additional constraints (try the command 'assume(a>0)' before integral or limit evaluation, for example):
Is a positive or negative?
Got:
Traceback (most recent call last):
File "/usr/bin/ncadoctest.py", line 1231, in run_one_test
self.run_one_example(test, example, filename, compileflags)
File "/usr/bin/sagedoctest.py", line 38, in run_one_example
OrigDocTestRunner.run_one_example(self, test, example, filename, compileflags)
File "/usr/bin/ncadoctest.py", line 1172, in run_one_example
compileflags, 1) in test.globs
File "<doctest __main__.example_8[3]>", line 1, in <module>
integrate(Integer(1)/(x**Integer(3) *(a+b*x)**(Integer(1)/Integer(3))),x)###line 639:
sage: integrate(1/(x^3 *(a+b*x)^(1/3)),x)
File "/usr/lib/python2.6/site-packages/sage/misc/functional.py", line 718, in integral
return x.integral(*args, **kwds)
File "expression.pyx", line 8153, in sage.symbolic.expression.Expression.integral (sage/symbolic/expression.cpp:30871)
File "/usr/lib/python2.6/site-packages/sage/symbolic/integration/integral.py", line 601, in integrate
return indefinite_integral(expression, v)
File "function.pyx", line 419, in sage.symbolic.function.Function.__call__ (sage/symbolic/function.cpp:4486)
File "/usr/lib/python2.6/site-packages/sage/symbolic/integration/integral.py", line 85, in _eval_
res = integrator(f, x)
File "/usr/lib/python2.6/site-packages/sage/symbolic/integration/external.py", line 19, in maxima_integrator
result = maxima.sr_integral(expression,v)
File "/usr/lib/python2.6/site-packages/sage/interfaces/maxima_lib.py", line 983, in sr_integral
raise error
RuntimeError: ECL says: Maxima asks:?mtext("Is ",a," positive or negative?")
**********************************************************************
File "/usr/share/sage/devel/sage/sage/interfaces/maxima_lib.py", line 649:
sage: integral(x^n,x)
Expected:
Traceback (most recent call last):
...
TypeError: Computation failed since Maxima requested additional constraints (try the command 'assume(n+1>0)' before integral or limit evaluation, for example):
Is n+1 zero or nonzero?
Got:
Traceback (most recent call last):
File "/usr/bin/ncadoctest.py", line 1231, in run_one_test
self.run_one_example(test, example, filename, compileflags)
File "/usr/bin/sagedoctest.py", line 38, in run_one_example
OrigDocTestRunner.run_one_example(self, test, example, filename, compileflags)
File "/usr/bin/ncadoctest.py", line 1172, in run_one_example
compileflags, 1) in test.globs
File "<doctest __main__.example_8[7]>", line 1, in <module>
integral(x**n,x)###line 649:
sage: integral(x^n,x)
File "/usr/lib/python2.6/site-packages/sage/misc/functional.py", line 718, in integral
return x.integral(*args, **kwds)
File "expression.pyx", line 8153, in sage.symbolic.expression.Expression.integral (sage/symbolic/expression.cpp:30871)
File "/usr/lib/python2.6/site-packages/sage/symbolic/integration/integral.py", line 601, in integrate
return indefinite_integral(expression, v)
File "function.pyx", line 419, in sage.symbolic.function.Function.__call__ (sage/symbolic/function.cpp:4486)
File "/usr/lib/python2.6/site-packages/sage/symbolic/integration/integral.py", line 85, in _eval_
res = integrator(f, x)
File "/usr/lib/python2.6/site-packages/sage/symbolic/integration/external.py", line 19, in maxima_integrator
result = maxima.sr_integral(expression,v)
File "/usr/lib/python2.6/site-packages/sage/interfaces/maxima_lib.py", line 983, in sr_integral
raise error
RuntimeError: ECL says: Maxima asks:?mtext("Is ",n+1," zero or nonzero?")
**********************************************************************
4 items had failures:
1 of 95 in __main__.example_0
1 of 3 in __main__.example_18
1 of 4 in __main__.example_23
2 of 11 in __main__.example_8
***Test Failed*** 5 failures.
For whitespace errors, see the file /home/francois/.sage/tmp/.doctest_maxima_lib.py
[17.3 s]
----------------------------------------------------------------------
The following tests failed:
sage -t -force_lib "devel/sage/sage/interfaces/maxima_lib.py"
Total time for all tests: 17.3 seconds
</pre><p>
sage -t -force_lib "devel/sage/sage/symbolic/integration/integral.py times out because:
</p>
<pre class="wiki">Trying:
integrate(sin(x)*cos(Integer(10)*x)*log(x), x)###line 462:_sage_ >>> integrate(sin(x)*cos(10*x)*log(x), x)
Expecting:
1/198*(11*cos(9*x) - 9*cos(11*x))*log(x) + 1/44*Ei(-11*I*x) - 1/36*Ei(-9*I*x) - 1/36*Ei(9*I*x) + 1/44*Ei(11*I*x)
Wrong number of arguments to gamma_incomplete
-- an error. To debug this try: debugmode(true);
Error in format: Unknown format directive.
Wrong number of arguments to ~:@M
^
while processing indirect format string:
~?
^
No restarts available.
Broken at LAMBDA.
</pre><p>
sage -t -force_lib "devel/sage/sage/symbolic/relation.py" times out because of this:
</p>
<pre class="wiki">Trying:
solve([sqrt(x) + sqrt(y) == Integer(5), x + y == Integer(10)], x, y)###line 492:_sage_ >>> solve([sqrt(x) + sqrt(y) == 5, x + y == 10], x, y)
Expecting:
[[x == -5/2*I*sqrt(5) + 5, y == 5/2*I*sqrt(5) + 5], [x == 5/2*I*sqrt(5) + 5, y == -5/2*I*sqrt(5) + 5]]
assoc: every list element must be an expression with two arguments; found: [sage147]
#0: simp_%solve(e=sage135,v=sage146,extraargs=[sage147])
-- an error. To debug this try: debugmode(true);
Error in format: Unknown format directive.
assoc: every list element must be an expression with two arguments; found: ~:M
^
while processing indirect format string:
~?
^
No restarts available.
</pre><p>
sage -t -force_lib "devel/sage/sage/symbolic/assumptions.py":
</p>
<pre class="wiki">Trying:
decl2.assume()###line 89:_sage_ >>> decl2.assume()
Expecting:
Traceback (most recent call last):
...
ValueError: Assumption is inconsistent
declare: inconsistent declaration declare(x,odd)
-- an error. To debug this try: debugmode(true);
Error in format: Unknown format directive.
declare: inconsistent declaration ~:M
^
while processing indirect format string:
~?
^
No restarts available.
</pre><p>
sage -t -force_lib "devel/sage/sage/symbolic/expression.pyx":
</p>
<pre class="wiki">Trying:
solve(acot(x),x)###line 7453:_sage_ >>> solve(acot(x),x)
Expecting:
[]
The number 0 isn't in the domain of cot
-- an error. To debug this try: debugmode(true);
Error in format: Unknown format directive.
The number ~:M isn't in the domain of ~A
^
while processing indirect format string:
~?
^
No restarts available.
</pre><p>
sage -t -force_lib "devel/sage/sage/structure/sage_object.pyx" is interesting:
</p>
<pre class="wiki">File "/usr/share/sage/devel/sage/sage/structure/sage_object.pyx", line 1053:
sage: print "x"; sage.structure.sage_object.unpickle_all()
Expected:
x...
Successfully unpickled ... objects.
Failed to unpickle 0 objects.
Got:
x
doctest:1: DeprecationWarning: Your word object is saved in an old file format since FiniteWord_over_OrderedAlphabet is deprecated and will be deleted in a future version of Sage (you can use FiniteWord_list instead). You can re-save your word by typing "word.save(filename)" to ensure that it will load in future versions of Sage.
doctest:1: DeprecationWarning: Your word object is saved in an old file format since AbstractWord is deprecated and will be deleted in a future version of Sage (you can use FiniteWord_list instead). You can re-save your word by typing "word.save(filename)" to ensure that it will load in future versions of Sage.
doctest:1: DeprecationWarning: Your word object is saved in an old file format since Word_over_Alphabet is deprecated and will be deleted in a future version of Sage (you can use FiniteWord_list instead). You can re-save your word by typing "word.save(filename)" to ensure that it will load in future versions of Sage.
doctest:1: DeprecationWarning: Your word object is saved in an old file format since Word_over_OrderedAlphabet is deprecated and will be deleted in a future version of Sage (you can use FiniteWord_list instead). You can re-save your word by typing "word.save(filename)" to ensure that it will load in future versions of Sage.
doctest:1: DeprecationWarning: ChristoffelWord_Lower is deprecated, use LowerChristoffelWord instead
* unpickle failure: load('/home/francois/.sage/temp/vrooom/13483/dir_2/pickle_jar/_class__sage_interfaces_maxima_MaximaFunction__.sobj')
Failed:
_class__sage_interfaces_maxima_MaximaFunction__.sobj
Successfully unpickled 585 objects.
Failed to unpickle 1 objects.
</pre><p>
sage -t -force_lib "devel/sage/sage/modules/free_module_element.pyx" now pass, so probably ecl-11.1.1 related.
</p>
<p>
sage -t -force_lib "devel/sage/sage/calculus/tests.py" (extracts):
</p>
<pre class="wiki">File "/usr/share/sage/devel/sage/sage/calculus/tests.py", line 107:
sage: integrate(log(1-x^2)/x, x)
Exception raised:
Traceback (most recent call last):
File "/usr/bin/ncadoctest.py", line 1231, in run_one_test
self.run_one_example(test, example, filename, compileflags)
File "/usr/bin/sagedoctest.py", line 38, in run_one_example
OrigDocTestRunner.run_one_example(self, test, example, filename, compileflags)
File "/usr/bin/ncadoctest.py", line 1172, in run_one_example
compileflags, 1) in test.globs
File "<doctest __main__.example_0[41]>", line 1, in <module>
integrate(log(Integer(1)-x**Integer(2))/x, x)###line 107:
sage: integrate(log(1-x^2)/x, x)
File "/usr/lib/python2.6/site-packages/sage/misc/functional.py", line 718, in integral
return x.integral(*args, **kwds)
File "expression.pyx", line 8153, in sage.symbolic.expression.Expression.integral (sage/symbolic/expression.cpp:30871)
File "/usr/lib/python2.6/site-packages/sage/symbolic/integration/integral.py", line 601, in integrate
return indefinite_integral(expression, v)
File "function.pyx", line 419, in sage.symbolic.function.Function.__call__ (sage/symbolic/function.cpp:4486)
File "/usr/lib/python2.6/site-packages/sage/symbolic/integration/integral.py", line 85, in _eval_
res = integrator(f, x)
File "/usr/lib/python2.6/site-packages/sage/symbolic/integration/external.py", line 19, in maxima_integrator
result = maxima.sr_integral(expression,v)
File "/usr/lib/python2.6/site-packages/sage/interfaces/maxima_lib.py", line 977, in sr_integral
return max_to_sr(maxima_eval(([max_integrate],[sr_to_max(SR(a)) for a in args])))
File "/usr/lib/python2.6/site-packages/sage/interfaces/maxima_lib.py", line 1228, in max_to_sr
args.append(max_to_sr(car(max_args)))
File "/usr/lib/python2.6/site-packages/sage/interfaces/maxima_lib.py", line 1228, in max_to_sr
args.append(max_to_sr(car(max_args)))
File "/usr/lib/python2.6/site-packages/sage/interfaces/maxima_lib.py", line 1228, in max_to_sr
args.append(max_to_sr(car(max_args)))
File "/usr/lib/python2.6/site-packages/sage/interfaces/maxima_lib.py", line 1221, in max_to_sr
sage_expr=SR(maxima(expr))
File "parent.pyx", line 915, in sage.structure.parent.Parent.__call__ (sage/structure/parent.c:6668)
File "coerce_maps.pyx", line 156, in sage.structure.coerce_maps.NamedConvertMap._call_ (sage/structure/coerce_maps.c:4045)
File "/usr/lib/python2.6/site-packages/sage/interfaces/maxima_abstract.py", line 1373, in _symbolic_
return R(self._sage_())
File "/usr/lib/python2.6/site-packages/sage/interfaces/maxima_abstract.py", line 1354, in _sage_
maxima=self.parent())
File "/usr/lib/python2.6/site-packages/sage/calculus/calculus.py", line 1646, in symbolic_expression_from_maxima_string
raise TypeError, "unable to make sense of Maxima expression '%s' in Sage"%s
TypeError: unable to make sense of Maxima expression 'li[2]' in Sage
</pre><pre class="wiki">File "/usr/share/sage/devel/sage/sage/calculus/tests.py", line 151:
sage: integrate(ceil(x^2 + floor(x)), x, 0, 5) # todo: Mathematica can do this
Expected:
integrate(ceil(x^2) + floor(x), x, 0, 5)
Got:
155/3
**********************************************************************
File "/usr/share/sage/devel/sage/sage/calculus/tests.py", line 189:
sage: integrate(sin(x), x, a, b)
Expected:
cos(a) - cos(b)
Got:
ceil(cos(a))
</pre><p>
sage -t -force_lib "devel/sage/sage/calculus/interpolators.pyx" is actually unrelated to maxima I think.
</p>
TicketkcrismanSat, 29 Jan 2011 14:52:31 GMT
https://trac.sagemath.org/ticket/7377#comment:34
https://trac.sagemath.org/ticket/7377#comment:34
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/7377#comment:32" title="Comment 32">fbissey</a>:
</p>
<blockquote class="citation">
<p>
ecl-10.4.1, maxima-5.23.2:<br />
sage -t --verbose -force_lib "devel/sage/sage/functions/special.py" times out because it stops:
</p>
<pre class="wiki">Trying:
elliptic_e(arccoth(Integer(1)), x**Integer(2)*e)###line 535:_sage_ >>> elliptic_e(arccoth(1), x^2*e)
Expecting:
elliptic_e(arccoth(1), x^2*e)
The number 1 isn't in the domain of acoth
</pre></blockquote>
<p>
Hmm, this must have to do with 5.23.2, because "Here arccoth doesn't have 1 in its domain, so we just hold the expression:" in the past. So Maxima must have improved something here.
</p>
<pre class="wiki"> sage: integrate(ceil(x^2 + floor(x)), x, 0, 5) # todo: Mathematica can do this
Expected:
integrate(ceil(x^2) + floor(x), x, 0, 5)
Got:
155/3
</pre><p>
If this is right, that's good. No idea what's going on with the next one.
</p>
<p>
In general, I'm seeing a lot of stuff that's related to having the newer Maxima. I think that we should either upgrade Maxima first, and take care of things related to better error handling/functionality in Maxima, and then address this ticket separately, OR do this first with our current Maxima and then upgrade Maxima. My preference would be to upgrade Maxima first, assuming one can do that relatively easily (would ECL also have to be upgraded? It's annoying that one has to do them simultaneously at times, at least with some of my slower test machines.).
</p>
TicketfbisseySat, 29 Jan 2011 19:35:56 GMT
https://trac.sagemath.org/ticket/7377#comment:35
https://trac.sagemath.org/ticket/7377#comment:35
<p>
I will do another run of tests with maxima-5.22.1 later. It is not too hard
to go from one version of maxima to another. At least you don't have to rebuild
anything else.
</p>
<p>
But it definitely looks like upgrading maxima would be a good thing,
we'll have to make a ticket about it.
</p>
TicketnbruinSat, 29 Jan 2011 21:32:58 GMT
https://trac.sagemath.org/ticket/7377#comment:36
https://trac.sagemath.org/ticket/7377#comment:36
<p>
Something blows up rather badly here. The <code>MAXIMA>></code> prompt indicates that you're dropped into to ECL debugger [the default behaviour of LISPs is to drop you into a debugger when an uncaught condition arises]. Ecllib tries to avoid this by executing any LISP code inside the LISP equivalent of try/except (being HANDLER-CASE). You can get tracebacks and code to see what is happening from the debugger (try ":h" to get help about the ECL debugger)
</p>
<pre class="wiki">----------------------------------------------------------------------
| Sage Version 4.6.1, Release Date: 2011-01-11 |
| Type notebook() for the GUI, and license() for information. |
----------------------------------------------------------------------
Loading Sage library. Current Mercurial branch is: dev
sage: elliptic_e(arccoth(1), x^2*e)
The number 1 isn't in the domain of acoth
-- an error. To debug this try: debugmode(true);
</pre><p>
This is Maxima printing something on the STDOUT. We should be catching this before it gets printed! In other words, find which routine in maxima prints this and monkey-patch it to raise an error *before* printing this. Apparently, maxima does raise an error after printing this, which normally gets caught on maxima's top level. But since we decapitated maxima, we're getting that now, and that is where the next thing goes wrong:
</p>
<pre class="wiki">Error in format: Unknown format directive.
The number ~:M isn't in the domain of ~A
^
while processing indirect format string:
~?
^
No restarts available.
Broken at LAMBDA.
MAXIMA>> :b
Backtrace:
> LAMBDA
> print-object
> common-lisp-user::sage-safe-apply
MAXIMA>> :le
(LAMBDA (CONDITION STREAM)
(FORMAT STREAM
"~?"
(SIMPLE-CONDITION-FORMAT-CONTROL CONDITION)
(SIMPLE-CONDITION-FORMAT-ARGUMENTS CONDITION)))
</pre><p>
so a FORMAT statement is failing here. Apparently "Condition" objects (roughly "exception" objects in python) can have a format string and items hanging off them. FORMAT is LISPs "printf", but with a much more baroque set of options. FORMAT format specifiers have been rumoured to be Turing complete. Let's look at the parameters:
</p>
<pre class="wiki">MAXIMA>> (SIMPLE-CONDITION-FORMAT-CONTROL CONDITION)
"The number ~:M isn't in the domain of ~A"
MAXIMA>> (SIMPLE-CONDITION-FORMAT-ARGUMENTS CONDITION)
NIL
</pre><p>
So the "~:M" is probably a Maxima extension to format which is not accessible at the point where we are trying it. The fact that there are no arguments also indicates that Maxima might be forming a condition object that is not fit for general consumption.
</p>
<p>
Let's see where this error really arose by stepping further up in the backtrace:
</p>
<pre class="wiki">MAXIMA>> :p
Broken at PRINT-OBJECT.
MAXIMA>> :le
(SI:LAMBDA-BLOCK PRINT-OBJECT
(SI::X STREAM)
(DECLARE (TYPE SIMPLE-CONDITION SI::X)
(SI::NO-CHECK-TYPE SI::X))
(IF *PRINT-ESCAPE*
(CALL-NEXT-METHOD)
((LAMBDA (CONDITION STREAM)
(FORMAT STREAM
"~?"
(SIMPLE-CONDITION-FORMAT-CONTROL CONDITION)
(SIMPLE-CONDITION-FORMAT-ARGUMENTS CONDITION)))
SI::X STREAM)))
{{{
So this is LISP trying to print a CONDITION object. Apparently, Maxima has created a CONDITION object that doesn't allow this method to work. This could be a bug in ECL or it could be Maxima being non-compliant.
}}}
MAXIMA>> :p
Broken at COMMON-LISP-USER::SAGE-SAFE-APPLY.
MAXIMA>> :le
(SI:LAMBDA-BLOCK COMMON-LISP-USER::SAGE-SAFE-APPLY
(COMMON-LISP-USER::FUNC COMMON-LISP-USER::ARGS)
(DECLARE (SI::C-GLOBAL))
(HANDLER-CASE
(VALUES
(APPLY COMMON-LISP-USER::FUNC COMMON-LISP-USER::ARGS))
(SERIOUS-CONDITION (COMMON-LISP-USER::CND)
(VALUES NIL (PRINC-TO-STRING COMMON-LISP-USER::CND)))))
MAXIMA>> COMMON-LISP-USER::FUNC
MAXIMA-EVAL
MAXIMA>> COMMON-LISP-USER::ARGS
((MEVAL* '((MSETQ) $SAGE1 (($ELLIPTIC_E) ((%ACOTH) 1) ((MTIMES) ((MEXPT) $X 2) ((%EXP) 1))))))
</pre><p>
Finally we're at the ecllib level. SAGE-SAFE-APPLY is the way ecllib tries to execute LISP code
As you can see, the arguments here indicate that this is the original call we started with, translated to maxima (well, the underlying LISP representation of maxima).
We know this raised an error, which gets processed by the HANDLER-CASE/SERIOUS-CONDITION. The PRINC-TO-STRING tries to make a string rendition of the CONDITION object, which fails for the reasons we have seen above.
</p>
<p>
So, the most direct way to solve the problem is to monkey-patch Maxima to raise an acceptable error *instead* of printing a message and sending a CONDITION object that crashes PRINC (which should be a near-universal printing routine). This should be relatively straightforward, because that Maxima routine already produces an acceptable string. Simply produce that string but instead of printing it, do an (ERROR string) or whatever is acceptable (the way "retrieve" gets monkey-patched in maximalib is already an example of that).
</p>
<p>
It does make me a bit pessimistic, though: Maxima improves some of its error reporting and in the process immediately blows up our error catching! This looks like something that is going to happen every time Maxima changes something. It's bad enough when dealing with the pexpect interface, but in this case we're basically using an unsupported and undocumented API! I know Robert Dodier is definitely sympathetic to making Maxima usable as a library, so perhaps if we can get reasonable functionality, he might be willing to take into account the required hooks when changing Maxima.
</p>
TicketnbruinSun, 30 Jan 2011 07:25:59 GMTattachment set
https://trac.sagemath.org/ticket/7377
https://trac.sagemath.org/ticket/7377
<ul>
<li><strong>attachment</strong>
set to <em>errorcatching.patch</em>
</li>
</ul>
<p>
improve maxima-eval error reporting
</p>
TicketnbruinSun, 30 Jan 2011 07:38:37 GMT
https://trac.sagemath.org/ticket/7377#comment:37
https://trac.sagemath.org/ticket/7377#comment:37
<p>
I have looked a little into the error reporting and it looks like maxima was not creating the error that crashed ecllib's error string creation routine -- instead it was maxima-eval, the maxima "top level" replacement we run to catch and interpret maxima's error reporting. Maxima's error reporting hasn't changed since 1985. It just happened that this was the first time we stumbled into an error message that was not properly handled. The new patch "errorcatching.patch" (to be applied after all the "rebased" patches) fixes this.
</p>
<p>
We now get:
</p>
<pre class="wiki">sage: arccoth(1).simplify()
-- an error. To debug this try: debugmode(true);
(result= MAXIMA-ERROR)
($error= ((MLIST) The number ~:M isn't in the domain of ~A 1 ACOTH))
TypeError: ECL says: The number 1 isn't in the domain of acoth
sage: elliptic_e(arccoth(1), x^2*e)
(result=
(MAXIMA_EVAL
. /usr/local/sage/4.6/local/share/maxima/5.22.1/share/orthopoly/orthopoly.lisp))
($error= ((MLIST) The number ~:M isn't in the domain of ~A 1 ACOTH))
(result= (MAXIMA_EVAL))
($error= ((MLIST) The number ~:M isn't in the domain of ~A 1 ACOTH))
-- an error. To debug this try: debugmode(true);
(result= MAXIMA-ERROR)
($error= ((MLIST) The number ~:M isn't in the domain of ~A 1 ACOTH))
elliptic_e(arccoth(1), x^2*e)
</pre><p>
So we see a bunch of things:
</p>
<ul><li>printing the error has now been turned off, but a quick glance at the code shows that the message <code>-- an error. To debug this try: debugmode(true);</code> cannot be turned off. I regard that a bug in Maxima and we can consider reporting that. We could also just monkeypatch MERROR.
</li><li>the error now gets properly reported
</li><li>there is a lot of junk diagnostic output generated by my fixed routine. Feel free to comment that back out.
</li><li>the actual simplification of elliptic_e (whatever is tried there) apparently is wrapped in a try/except and the error reported by ecl is nicely hidden and the result is left unchanged.
</li></ul><p>
This should be closer to how sage handled this first.
</p>
TicketnbruinTue, 01 Feb 2011 04:37:39 GMT
https://trac.sagemath.org/ticket/7377#comment:38
https://trac.sagemath.org/ticket/7377#comment:38
<p>
The following doctest from calculus.py now goes wrong:
</p>
<pre class="wiki">limit(-e^(x^2)*erf(x) + e^(x^2), x=oo)
</pre><p>
Which stumbles at calculus.calculus.limit at these lines:
</p>
<pre class="wiki"> 1122 return l.sage()
1123 return ex.parent()(l)
</pre><p>
Two return statements??? A little <code>hg -blame</code> points to <a class="closed ticket" href="https://trac.sagemath.org/ticket/7661" title="defect: maxima interface gives precedence to function dictionary instead of ... (closed: fixed)">#7661</a>. Indeed, commenting out line 1122 fixes a lot of the limit problems. However, Burcin put in that line for a reason, I assume, so I'm hesitant to just commit a reversal.
</p>
<p>
Note that the issue of <a class="closed ticket" href="https://trac.sagemath.org/ticket/7661" title="defect: maxima interface gives precedence to function dictionary instead of ... (closed: fixed)">#7661</a> is exactly due to a namespace collapse from SR -> Maxima; something this interface could eventually solve much more elegantly, by just mapping (at no cost) SR.var('x') to the maxima identifier "sage_SR_var_x".
</p>
TicketfbisseyTue, 01 Feb 2011 08:57:13 GMT
https://trac.sagemath.org/ticket/7377#comment:39
https://trac.sagemath.org/ticket/7377#comment:39
<p>
two return statements is indeed strange. Is the second return ever reached?
Could it be a left over forgotten there? Looking at the code I am not sure
what ex.parent()(l) is supposed to be.
I haven't had time to test the errorcatching patch but will try ASAP.
One of my testing friend noted that maxima as a lib and ecl compiled
with thread support are not compatible (ever seen a SIGPWR?). I am mentioning
that, in case it becomes the default in ecl in the future.
</p>
TicketnbruinTue, 01 Feb 2011 17:28:01 GMT
https://trac.sagemath.org/ticket/7377#comment:40
https://trac.sagemath.org/ticket/7377#comment:40
<blockquote class="citation">
<p>
two return statements is indeed strange. Is the second return ever reached?
</p>
</blockquote>
<p>
No, it isn't. However, Burcin apparently thought that <code>l.sage()</code> would give better results. I'm actually thankful that he left in the original return statement because that served as a nice flag that something had changed there.
</p>
<blockquote class="citation">
<p>
Could it be a left over forgotten there? Looking at the code I am not sure
what ex.parent()(l) is supposed to be.
</p>
</blockquote>
<p>
It is "Coerce l into the parent of ex", the original input parameter, i.e., coerce l into the Symbolic Ring. In the new code, "sr_limit" produces something that is hopefully *coercible* into the <a class="missing wiki">SymbolicRing?</a> -- it probably isn't a maxima object at all anymore. I think in all cases it's better to coerce into SR instead of calling l.sage(): On maxima objects it should be about the same and if limit produces something that cannot be represented in the <a class="missing wiki">SymbolicRing?</a> we should get an error. I'll ping him about it.
</p>
<blockquote class="citation">
<p>
One of my testing friend noted that maxima as a lib and ecl compiled
with thread support are not compatible (ever seen a SIGPWR?). I am mentioning
that, in case it becomes the default in ecl in the future.
</p>
</blockquote>
<p>
Good to know! A little googling found <a class="ext-link" href="http://www.hpl.hp.com/personal/Hans_Boehm/gc/debugging.html"><span class="icon"></span>http://www.hpl.hp.com/personal/Hans_Boehm/gc/debugging.html</a>
It's the garbage collector that uses SIGXCPU and SIGPWR to synchronise cross-thread garbage collection. So if we want ecllib+threads we need to adjust the sage signal handler to properly handle those. BoehmGC is made for integration into C programs, so this may be doable.
</p>
TicketfbisseyWed, 02 Feb 2011 03:36:30 GMT
https://trac.sagemath.org/ticket/7377#comment:41
https://trac.sagemath.org/ticket/7377#comment:41
<p>
Re-running sage -testall with maxima-lib enabled, ecl-10.4.1 maxima-5.22.1, sage-4.6.2_alpha3. Most of the time out have disappeared expect for three which at first
sight are unrelated, but don't fail without maxima-lib
</p>
<pre class="wiki">sage -t -force_lib devel/sage/sage/misc/randstate.pyx
sage -t -force_lib devel/sage/sage/interfaces/psage.py
sage -t -force_lib devel/sage/sage/interfaces/sage0.py
</pre><p>
From the first one:
</p>
<pre class="wiki">Trying:
subsage = Sage()###line 134:_sage_ >>> subsage = Sage()
Expecting nothing
ok
Trying:
s = ZZ(subsage('initial_seed()'))###line 135:_sage_ >>> s = ZZ(subsage('initial_seed()'))
Expecting nothing
</pre><p>
And it hangs there.
</p>
<p>
I also have SIGFPE in the following
</p>
<pre class="wiki">sage -t -force_lib "devel/sage/sage/functions/other.py" *
sage -t -force_lib devel/sage/sage/functions/log.py *
sage -t -force_lib devel/sage/sage/symbolic/constants.py
sage -t -force_lib devel/sage/sage/symbolic/pynac.pyx
sage -t -force_lib devel/sage/sage/rings/complex_number.pyx
sage -t -force_lib devel/sage/sage/rings/real_double.pyx
sage -t -force_lib devel/sage/sage/rings/real_mpfr.pyx
sage -t -force_lib devel/sage/sage/libs/mpmath/utils.pyx
sage -t -force_lib devel/sage/sage/libs/mpmath/ext_libmp.pyx
sage -t -force_lib devel/sage/sage/libs/mpmath/ext_impl.pyx
sage -t -force_lib devel/sage/sage/libs/mpmath/ext_main.pyx
sage -t -force_lib devel/sage/sage/calculus/calculus.py *
sage -t -force_lib devel/sage/sage/structure/element.pyx
sage -t -force_lib devel/sage/sage/schemes/elliptic_curves/ell_point.py
sage -t -force_lib devel/sage/sage/schemes/elliptic_curves/ell_generic.py *
</pre><p>
The stars indicate where I also had some verbose out from maxima, usually ending
with
</p>
<pre class="wiki">($error= ((MLIST SIMP) No error.))
</pre><p>
And there is quite few more. I am doing another run with the little correction
in calculus.py to see if that solve some of them.
</p>
TicketfbisseyWed, 02 Feb 2011 04:02:54 GMT
https://trac.sagemath.org/ticket/7377#comment:42
https://trac.sagemath.org/ticket/7377#comment:42
<p>
scrap the three time out. They still happen without maxima-lib I was mistaken.
</p>
TicketburcinWed, 02 Feb 2011 06:19:38 GMT
https://trac.sagemath.org/ticket/7377#comment:43
https://trac.sagemath.org/ticket/7377#comment:43
<p>
Thank you all for working on this again. I hope this will also solve some of the long standing issues we had with the maxima interface, like setting domains for variables <a class="new ticket" href="https://trac.sagemath.org/ticket/6862" title="defect: Mixing of different domains for symbolic variables (new)">#6862</a>, or recognizing special symbols <a class="closed ticket" href="https://trac.sagemath.org/ticket/6882" title="defect: bugs in conversion of variable names from Maxima to Sage (closed: fixed)">#6882</a>.
</p>
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/7377#comment:40" title="Comment 40">nbruin</a>:
</p>
<blockquote class="citation">
<blockquote class="citation">
<p>
two return statements is indeed strange. Is the second return ever reached?
</p>
</blockquote>
<p>
No, it isn't. However, Burcin apparently thought that <code>l.sage()</code> would give better results. I'm actually thankful that he left in the original return statement because that served as a nice flag that something had changed there.
</p>
</blockquote>
<p>
It was clearly a mistake on my part to leave the second return statement. I'm glad it ended up being useful though.
</p>
<p>
I don't have much time these days to investigate this. So it would be great if someone can update me on the progress. Especially, when rebasing Robert's patch to split off the maxima interface, did you merge in the changes that were made to sage/interfaces/maxima.py in the meantime?
</p>
<blockquote class="citation">
<blockquote class="citation">
<p>
Could it be a left over forgotten there? Looking at the code I am not sure
what ex.parent()(l) is supposed to be.
</p>
</blockquote>
<p>
It is "Coerce l into the parent of ex", the original input parameter, i.e., coerce l into the Symbolic Ring. In the new code, "sr_limit" produces something that is hopefully *coercible* into the <a class="missing wiki">SymbolicRing?</a> -- it probably isn't a maxima object at all anymore. I think in all cases it's better to coerce into SR instead of calling l.sage(): On maxima objects it should be about the same and if limit produces something that cannot be represented in the <a class="missing wiki">SymbolicRing?</a> we should get an error. I'll ping him about it.
</p>
</blockquote>
<p>
The operation we are using is conversion, not coercion. IMHO, the code for converting maxima objects (of any kind, pexpect or library) to Sage symbolics objects should be within the maxima objects. Most of this functionality is in sage/calculus/calculus.py at the moment, I would like to see that moved to sage/interfaces/maxima.py or it's variants.
</p>
<p>
Adding a .sage() method to maxima interface objects was a step in this direction. This method knows which lookup tables to use to convert functions, etc. from maxima back to Sage. The code for this function is simply
</p>
<pre class="wiki"> def _sage_(self):
import sage.calculus.calculus as calculus
return calculus.symbolic_expression_from_maxima_string(self.name(),
maxima=self.parent())
</pre><p>
around line 1775 of sage/interfaces/maxima.py. I would expect this to work for the library interface to maxima as well, since AFAIK, this is also string based ATM.
</p>
<p>
I am not quite sure what a conversion to the symbolic ring does for maxima interface objects. I don't expect it to have special behavior if the input is a maxima interface object. It would make sense, if it called the .sage() or ._sage_() methods of the argument though.
</p>
<p>
Sorry I can't be more helpful.
</p>
TicketnbruinWed, 02 Feb 2011 18:22:24 GMT
https://trac.sagemath.org/ticket/7377#comment:44
https://trac.sagemath.org/ticket/7377#comment:44
<p>
Thank you, Burcin. That is very useful information indeed.
</p>
<blockquote class="citation">
<p>
I don't have much time these days to investigate this. So it would be great if someone can update me on the progress. Especially, when rebasing Robert's patch to split off the maxima interface, did you merge in the changes that were made to sage/interfaces/maxima.py in the meantime?
</p>
</blockquote>
<p>
I'll leave that to JP
</p>
<blockquote class="citation">
<p>
The operation we are using is conversion, not coercion. IMHO, the code for converting maxima objects (of any kind, pexpect or library) to Sage symbolics objects should be within the maxima objects. Most of this functionality is in sage/calculus/calculus.py at the moment, I would like to see that moved to sage/interfaces/maxima.py or it's variants.
</p>
</blockquote>
<p>
OK, conversion indeed. Good to know there is a philosophy behind the change
</p>
<blockquote class="citation">
<p>
Adding a .sage() method to maxima interface objects was a step in this direction. This method knows which lookup tables to use to convert functions, etc. from maxima back to Sage.
</p>
</blockquote>
<p>
Ultimately, this model might fit better with maximalib, but currently it means some refactoring of what we already had (or just go back to the SR coercion)
</p>
<blockquote class="citation">
<p>
around line 1775 of sage/interfaces/maxima.py. I would expect this to work for the library interface to maxima as well, since AFAIK, this is also string based ATM.
</p>
</blockquote>
<p>
With the fastcalculus patch it is not, though. In principle one could try to polish the abstract_maxima and maxima_lib patches so that they give a drop-in string-based library interface to maxima, but I never really went that far. That would be (probably boring but) very well-defined project and might speed up adoption.
</p>
<p>
What happens with the current set of patches:
</p>
<ul><li>a maxima_lib interface is made available that in principle should be a drop-in replacement for maxima (except that only one instance can exist)
</li><li>this interface adds some extra methods to get "under the hood" of objects:
</li></ul><blockquote>
<blockquote>
<p>
(1) There is an .ecl() method that returns the underlying <a class="missing wiki">EclObject?</a> (i.e., direct access to the LISP object implementing the maxima object)
</p>
</blockquote>
</blockquote>
<blockquote>
<blockquote>
<p>
(2) the maxima() method also accepts <a class="missing wiki">EclObjects?</a> and returns the appropriate wrapper, so maxima(M.ecl()) and maxima(eclobject).ecl() are supposed to be the identity (In a strong sense: The python wrapped might change Id but the ecl object not) where defined.
</p>
</blockquote>
</blockquote>
<blockquote>
<blockquote>
<p>
(3) sr_to_max(), a method to translate an SR object into an <a class="missing wiki">EclObject?</a> ready for wrapping in maxima.
</p>
</blockquote>
</blockquote>
<blockquote>
<blockquote>
<p>
(4) max_to_sr(), a method to translate an <a class="missing wiki">EclObject?</a> representing a maxima expression to something in or coercible to SR. Note that maxima expressions can be lists, which should be translated into a python list of SR elements, so the mapping cannot be perfectly into SR.
</p>
</blockquote>
</blockquote>
<blockquote>
<blockquote>
<p>
(5) methods sr_limit, sr_sum, sr_integrate which expect arguments living in SR and return something convertible to SR
</p>
</blockquote>
</blockquote>
<p>
The idea is that (3) and (4) offer a way to go back and forth between SR and maxima without using strings. maxima(E) and maxima(sr_to_max(E)) should have the same result. Similarly, SR(M) and SR(max_to_sr(M.ecl())) should have the similar result. Under the hood, sr_to_max and max_to_sr keep mappings between SR symbols and their <a class="missing wiki">EclObject?</a> counterparts. They build up these mappings via the string-based interface, but avoid strings once they know the mappings.
</p>
<p>
The methods in (5) were an attempt to make "compute limit/sum/integral via maxima" dependent on which maxima interface was in use. The old maxima-interface got stubs that just returned the result of calling the appropriate maxima expression, which returns a maxima expression, which is coercible into SR again.
</p>
<p>
The maxima-lib implementation uses sr_to_max and max_to_sr as much as possible and returns the result of a max_to_sr, so that should be coercible into SR as well.
</p>
<p>
Doing it this way (at the time) was the smallest change and left as much as possible in the calculus.limit routine. The general setup fits will in Burcin's philosophy, but is presently broken because the result of a max_to_sr likely doesn't have a .sage() method. An alternative would be to push the actual conversion of the answer to SR into the sr_limit routine as well. But then one would have to tell sr_limit into which SR the answer has to be pushed. (I guess expr.parent())
</p>
<p>
I think the _proper_ way to do all these computations is to construct a dummy_limit or a dummy_integral in SR first ("inert" limit and "inert" integral being the less opinionated synonyms), convert that to maxima (via sr_to_max or string-based), call the appropriate simplification on it there (note that sr_to_max will absolutely not do any simplification. It's just mapping over expression trees) and then pull the answer back via max_to_sr or string based.
</p>
<p>
To come up with a truly robust design for this (the present was just a first hack and proof-of-concept), people who know a lot about SR and the general calculus architecture need to be involved. I've tried to show with various examples on this ticket that you don't need to understand much of lisp to make sense of what happens in maxima. The sage side of this is really much more complicated than the maxima side. The ECL objects representing maxima expressions look messy and have a lot of parentheses, but have a very straightforward structure.
</p>
<p>
Finally for (4): I know maxima functions like li[n] and psi[n] are not translated yet, because recognising them means looking a bit deeper in the maxima constructs. This is straightforward to do. There may be more of these constructs. Whoever wrote the string-based converter probably knows them already, because there they need special treatment too.
</p>
TicketnbruinFri, 11 Feb 2011 09:05:01 GMTdescription changed
https://trac.sagemath.org/ticket/7377#comment:45
https://trac.sagemath.org/ticket/7377#comment:45
<ul>
<li><strong>description</strong>
modified (<a href="/ticket/7377?action=diff&version=45">diff</a>)
</li>
</ul>
TicketnbruinFri, 11 Feb 2011 09:06:50 GMTattachment set
https://trac.sagemath.org/ticket/7377
https://trac.sagemath.org/ticket/7377
<ul>
<li><strong>attachment</strong>
set to <em>trac_7377-fastcalculus-p1.patch</em>
</li>
</ul>
<p>
improved fastcalculus (includes previous fixes)
</p>
TicketnbruinFri, 11 Feb 2011 09:11:20 GMT
https://trac.sagemath.org/ticket/7377#comment:46
https://trac.sagemath.org/ticket/7377#comment:46
<p>
doctesting on 4.6.1 yields failures in only 12 files, and most of these are just changed formatting of output, numerical noise because floats are now binarily copied rather than transcribed via decimal string representations, and because some errors get reported differently. (For ECL everything is a <a class="missing wiki">RuntimeError?</a>, for instance).
</p>
<p>
List here:
</p>
<ul><li><code>devel/sage/sage/symbolic/assumptions.py</code>: "Assumption
</li></ul><p>
is inconsistent" errors get reported differently
</p>
<ul><li><code>devel/sage/sage/symbolic/function_factory.py</code>: Serious issues with
</li></ul><p>
translating FDerivative constructs (it doesn't work at the moment)
</p>
<ul><li><code>devel/sage/sage/symbolic/expression.pyx</code>: A strange
</li></ul><p>
issue with <code>(x*log(9)).simplify_log('all')</code>. Oddly,
<code>(x*log(3/7)).simplify_log('all')</code> does behave correctly.
</p>
<ul><li><code>devel/sage/sage/symbolic/integration/integral.py</code>:
</li></ul><p>
"Maxima asks a question" errors get reported differently, float issues
</p>
<ul><li><code>devel/sage/sage/interfaces/maxima.py</code>: "Maxima asks
</li></ul><p>
a question" errors get reported differently. These doctests are wrong, because
they test the maxima_lib interface via calculus, not a real maxima interface.
</p>
<ul><li><code>devel/sage/sage/interfaces/maxima_abstract.py</code>:
</li></ul><p>
These doctests were never adapted
</p>
<ul><li><code>devel/sage/sage/calculus/calculus.py</code>: Whitespace
</li></ul><p>
and nintegral reports failure differently.
</p>
<ul><li><code>devel/sage/sage/calculus/wester.py</code>: Looks like
</li></ul><p>
correct answer, but differently collected.
</p>
<ul><li><code>devel/sage/sage/calculus/tests.py</code>: Odd errors. They seem to depend on
</li></ul><p>
context. Perhaps assumptions that aren't properly forgotten or max_to_sr cache
that gets spoilt?
</p>
<ul><li><code>devel/sage/sage/calculus/desolvers.py</code>: lots of
</li></ul><p>
problems. The desolve interface probably needs treatment like the to_poly_solve
routine.
</p>
<ul><li><code>devel/sage/sage/calculus/functional.py</code>: "Maxima
</li></ul><p>
asks a question" gets reported differently
</p>
<ul><li><code>devel/sage/sage/symbolic/assumptions.py</code>:
</li></ul><p>
Inconsistent assumptions get reported differently.
</p>
<p>
Most of these are a matter of changing the doctests to the generated answer, but
a few serious issues remain.
</p>
TicketfbisseyFri, 11 Feb 2011 09:21:09 GMT
https://trac.sagemath.org/ticket/7377#comment:47
https://trac.sagemath.org/ticket/7377#comment:47
<p>
David Kirkby and I have started to look at up updating ecl to 11.1.1 in <a class="closed ticket" href="https://trac.sagemath.org/ticket/10766" title="defect: Update ECL to the latest upstream release. (closed: fixed)">#10766</a>.
From my own experiments some of this patch set will need rebasing if it goes in.
</p>
<p>
I will certainly test your new patch.
</p>
TicketnbruinMon, 14 Feb 2011 07:02:37 GMTattachment set
https://trac.sagemath.org/ticket/7377
https://trac.sagemath.org/ticket/7377
<ul>
<li><strong>attachment</strong>
set to <em>trac_7377-better-ask-error.patch</em>
</li>
</ul>
<p>
improved formatting of error message when maxima asks a question
</p>
TicketnbruinMon, 14 Feb 2011 07:12:01 GMT
https://trac.sagemath.org/ticket/7377#comment:48
https://trac.sagemath.org/ticket/7377#comment:48
<p>
the lisp function <code>retrieve</code> in maxima is responsible for asking questions, so we just monkey-patch it to throw an error with an informative message instead. The patch trac_7377-better-ask-error.patch improves the readability of this message by executing exactly the original code in retrieve, but wrapped in a <code>(with-output-to-string (*standard-output*) ...)</code>. The method is generally applicable and may be useful in adapting other printing bits.
</p>
<p>
Oddly enough, this patch does not invalidate any additional doctests, but:
</p>
<pre class="wiki">sage -t "devel/sage-devel/sage/interfaces/maxima_lib.py"
**********************************************************************
Error: TAB character found.
</pre><p>
so perhaps maxima inserts a TAB in the error message. Are TABs not allowed in doctest output?
(it looks like one gets produced and matched by a "..." in the doctest template). A <code>sage -t --verbose</code> shows that no individual test fails.
</p>
TicketfbisseyMon, 14 Feb 2011 09:17:32 GMT
https://trac.sagemath.org/ticket/7377#comment:49
https://trac.sagemath.org/ticket/7377#comment:49
<p>
I accidentally introduced a TAB by mistake in a doctest the other and it was flagged so I'd say it is not allowed. Good news, bad news time. David Kirkby and I are updating ecl to 11.1.1 and maxima to 5.23.2 in <a class="closed ticket" href="https://trac.sagemath.org/ticket/10766" title="defect: Update ECL to the latest upstream release. (closed: fixed)">#10766</a> (ecl) and <a class="closed ticket" href="https://trac.sagemath.org/ticket/10773" title="enhancement: Update Maxima to the latest upstream release. (closed: fixed)">#10773</a> (maxima).
</p>
<p>
The bad news is that the current patches in this ticket will need rebasing again because of the patches I had to apply for ecl-11.1.1. Actually I wouldn't mind some input on <a class="closed ticket" href="https://trac.sagemath.org/ticket/10766" title="defect: Update ECL to the latest upstream release. (closed: fixed)">#10766</a> as it seem to resurrect <a class="closed ticket" href="https://trac.sagemath.org/ticket/6189" title="defect: [with patch, positive review] 'integrate' produces incorrect answer (closed: fixed)">#6189</a>.
</p>
TicketfbisseyMon, 14 Feb 2011 09:21:24 GMT
https://trac.sagemath.org/ticket/7377#comment:50
https://trac.sagemath.org/ticket/7377#comment:50
<p>
I forgot I already posted about ecl. Anyway, Nils could you put in the description the list of patches to apply and in which order if it is relevant?
</p>
<p>
I mean, is the error_catching.patch still necessary with the 2 new patches?
</p>
TicketfbisseyMon, 14 Feb 2011 09:23:38 GMT
https://trac.sagemath.org/ticket/7377#comment:51
https://trac.sagemath.org/ticket/7377#comment:51
<p>
Never mind. I'll just go to bed.
</p>
TicketnbruinMon, 14 Feb 2011 16:34:40 GMTdescription changed
https://trac.sagemath.org/ticket/7377#comment:52
https://trac.sagemath.org/ticket/7377#comment:52
<ul>
<li><strong>description</strong>
modified (<a href="/ticket/7377?action=diff&version=52">diff</a>)
</li>
</ul>
TicketkcrismanMon, 14 Feb 2011 19:17:42 GMT
https://trac.sagemath.org/ticket/7377#comment:53
https://trac.sagemath.org/ticket/7377#comment:53
<p>
<a class="closed ticket" href="https://trac.sagemath.org/ticket/10766" title="defect: Update ECL to the latest upstream release. (closed: fixed)">#10766</a> and <a class="closed ticket" href="https://trac.sagemath.org/ticket/10773" title="enhancement: Update Maxima to the latest upstream release. (closed: fixed)">#10773</a> now both have positive review. <a class="closed ticket" href="https://trac.sagemath.org/ticket/10766" title="defect: Update ECL to the latest upstream release. (closed: fixed)">#10766</a> vis-a-vis <a class="closed ticket" href="https://trac.sagemath.org/ticket/6189" title="defect: [with patch, positive review] 'integrate' produces incorrect answer (closed: fixed)">#6189</a> does happen, but maybe it just doesn't matter - that's what we concluded, but we'll see how the release manager(s) feels (feel).
</p>
<p>
I would like to work on fixing some of these issues soon enough for this to be in 4.7, but I have a feeling the desolver and abstract derivative piece might be a little time-consuming. At worst with the deriv, we could just figure out what Sage was passing/getting from Maxima before and jerry-rig that, though it's not a long-term solution.
</p>
TicketnbruinMon, 14 Feb 2011 20:30:12 GMT
https://trac.sagemath.org/ticket/7377#comment:54
https://trac.sagemath.org/ticket/7377#comment:54
<blockquote class="citation">
<blockquote>
<p>
desolver
</p>
</blockquote>
</blockquote>
<p>
This might be not so bad.
</p>
<p>
The main thing there is that the call forms for "desolve" are rather complicated, because there are all kinds of auxiliary arguments. to_poly_solve had a similar problem. I solved that by declaring an explicit to_poly_solve method on maxima_lib.<a class="missing wiki">MaximaElement?</a>.
</p>
<p>
Probably just parsing the optional arguments and putting them together in the right kind of structure (see to_poly_solve for an example) solves most problems.
</p>
<p>
I don't know how bad the structures are that come back from desolve, but for most cases I have had surprisingly little problems in that direction.
</p>
<blockquote class="citation">
<p>
abstract derivative
</p>
</blockquote>
<p>
The whole <code>D[0](f)</code> syntax needs separate treatment. I realized later that currently, only
<code>D[i,j,k](f)(x1,x2,...,xn)</code> is allowed if <code>x1,...,xn</code> are distinct symbolic variables. This surprised me a bit. Sage support for functional derivatives is only rudimentary.
</p>
<p>
I think that if we have an expression: <code>D[i0,...,ir](f)(e0,...,en)</code>, we should just do
<code>diff( f(t0,...,tn), [[t0,...,tn][i] for i in [i0,...,ir]]).subs({t0:e0,...,tn:en})</code>
i.e., introduce temporary variables t0,...,tn to take the appropriate derivate relative to named variables and then specialize to the evaluation point requested. Is there a reason this approach has not been taken? Just lack of need/implementation time?
</p>
<p>
In Maxima one can take exactly the same approach:
</p>
<pre class="wiki">at(diff( f(t0,t1,t2,t3) , t0,1,t1,1,t0,1 ), [t0=e0,t1=e1,t2=e2])
</pre><p>
the documentation of at is scary: substitutions are done in series, not in parallel. That's basically a bug given the intended use of the routine, even though it is documented behaviour. However, if we make sure that our temporary variables are truly unique, there should be no problem. Perhaps call <code>gensym</code>.
</p>
TicketfbisseyTue, 15 Feb 2011 02:57:21 GMT
https://trac.sagemath.org/ticket/7377#comment:55
https://trac.sagemath.org/ticket/7377#comment:55
<p>
OK so I tested the new patch set on sage-on-gentoo and it is strange. I see all the doctests failures that Nils is seeing. Plus a few more strangely enough in scheme/elliptic_curves/ that you wouldn't think are related. But I also get a lot of SIGFPE all over the place from seemingly unrelated components (mpmath, pynac...).
They go away when I rebuild without the patches.
</p>
<p>
I fail to see the cause to effect relation between maxima-lib and these, but there they are.
</p>
<p>
I almost forgot I have an unpickling failure as well
</p>
<pre class="wiki">sage -t -force_lib "devel/sage-main/sage/structure/sage_object.pyx"
**********************************************************************
File "/usr/share/sage/devel/sage-main/sage/structure/sage_object.pyx", line 1053:
sage: print "x"; sage.structure.sage_object.unpickle_all()
Expected:
x...
Successfully unpickled ... objects.
Failed to unpickle 0 objects.
Got:
x
doctest:1: DeprecationWarning: Your word object is saved in an old file format since FiniteWord_over_OrderedAlphabet is deprecated and will be deleted in a future version of Sage (you can use FiniteWord_list instead). You can re-save your word by typing "word.save(filename)" to ensure that it will load in future versions of Sage.
doctest:1: DeprecationWarning: Your word object is saved in an old file format since AbstractWord is deprecated and will be deleted in a future version of Sage (you can use FiniteWord_list instead). You can re-save your word by typing "word.save(filename)" to ensure that it will load in future versions of Sage.
doctest:1: DeprecationWarning: Your word object is saved in an old file format since Word_over_Alphabet is deprecated and will be deleted in a future version of Sage (you can use FiniteWord_list instead). You can re-save your word by typing "word.save(filename)" to ensure that it will load in future versions of Sage.
doctest:1: DeprecationWarning: Your word object is saved in an old file format since Word_over_OrderedAlphabet is deprecated and will be deleted in a future version of Sage (you can use FiniteWord_list instead). You can re-save your word by typing "word.save(filename)" to ensure that it will load in future versions of Sage.
doctest:1: DeprecationWarning: ChristoffelWord_Lower is deprecated, use LowerChristoffelWord instead
* unpickle failure: load('/home/fbissey/.sage/temp/QCD_nzi3/26167/dir_2/pickle_jar/_class__sage_interfaces_maxima_MaximaFunction__.sobj')
Failed:
_class__sage_interfaces_maxima_MaximaFunction__.sobj
Successfully unpickled 585 objects.
Failed to unpickle 1 objects.
</pre>
TicketnbruinTue, 15 Feb 2011 04:18:56 GMT
https://trac.sagemath.org/ticket/7377#comment:56
https://trac.sagemath.org/ticket/7377#comment:56
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/7377#comment:55" title="Comment 55">fbissey</a>:
</p>
<blockquote class="citation">
<blockquote>
<p>
But I also get a lot of SIGFPE all over the place from seemingly unrelated components
</p>
</blockquote>
</blockquote>
<p>
ECL does normally install SIG handlers, but we try to put them back (at the time Juanjo said this should be basically safe). The responsible code is in <code>sage.libs.ecl.init_ecl()</code>,
<code>sage/libs/ecl.pyx:131</code>.
</p>
<pre class="wiki"> #get all the signal handlers (does any system have signal numbers above 32?)
for i in range(1,33):
sigaction(i,NULL,&(act[i]))
#initialize ECL
cl_boot(0, argv)
#and put the signal handlers back
for i in range(1,33):
sigaction(i,&(act[i]),NULL)
</pre><p>
To see if this is the culprit, take a pristine sage and ensure that sage.libs.ecl_init() gets called upon initialization (i.e., insert a call into some module to ensure this gets called. Normally it doesn't)
Now run the SIGFPE producing doctests. Do they offend again? Perhaps you can improve ecllib's initialization?
</p>
<p>
Other things to watch out for:
</p>
<ul><li>Your Boehm-Weiser GC might be built with different options
</li><li>Make sure that ecl.so links against the same MPIR/GMP library. Having two GMPs hang around will definitely wreak havoc.
</li></ul><p>
(I think I saw the pickling error too. Some gherkin expert can probably easily pinpoint what's wrong and how to fix it)
</p>
TicketjpfloriTue, 15 Feb 2011 17:05:15 GMT
https://trac.sagemath.org/ticket/7377#comment:57
https://trac.sagemath.org/ticket/7377#comment:57
<p>
I produced new versions of the patches based on Sage 4.6.2.alpha4, ECL 11.1.1 of #10766 and Maxima 5.23.1 of <a class="closed ticket" href="https://trac.sagemath.org/ticket/10773" title="enhancement: Update Maxima to the latest upstream release. (closed: fixed)">#10773</a>.
</p>
<p>
I think I forgot to include some changes in Sage in the previous rebased patches, things should be better with those versions.
</p>
<p>
The patches will follow shortly.
</p>
<p>
I'm currently running "make ptest" to check I get the same failures as what was posted above.
</p>
<p>
I'm also currently trying to get rid of the Pexpect class inheritage of <a class="missing wiki">MaximaAbstract?</a> and <a class="missing wiki">MaximaLib?</a> classes.
</p>
<p>
The best idea I got so far is to split all the non-pexpect and non-communication things of Sage pexpect class into a parent class and make <a class="missing wiki">MaximaAbstract?</a> inherit from that class so that we still have access to all the nice features defined in Pexpect class.
</p>
<p>
<a class="missing wiki">MaximaLib?</a> would just inherit <a class="missing wiki">MaximaAbstract?</a> and Maxima woulb inherit both <a class="missing wiki">MaximaAbstract?</a> and Pexpect.
</p>
<p>
I'll post this set of patches asap.
</p>
TicketjpfloriTue, 15 Feb 2011 17:06:50 GMTattachment set
https://trac.sagemath.org/ticket/7377
https://trac.sagemath.org/ticket/7377
<ul>
<li><strong>attachment</strong>
set to <em>trac_7377-abstract-maxima_p2.patch</em>
</li>
</ul>
<p>
Patch based on Sage 4.6.2.alpha4, ECL 11.1.1 and Maxima 5.23.1, apply 1
</p>
TicketjpfloriTue, 15 Feb 2011 17:07:05 GMTattachment set
https://trac.sagemath.org/ticket/7377
https://trac.sagemath.org/ticket/7377
<ul>
<li><strong>attachment</strong>
set to <em>trac_7377-maximalib_p2.patch</em>
</li>
</ul>
<p>
Patch based on Sage 4.6.2.alpha4, ECL 11.1.1 and Maxima 5.23.1, apply 2
</p>
TicketjpfloriTue, 15 Feb 2011 17:07:24 GMTattachment set
https://trac.sagemath.org/ticket/7377
https://trac.sagemath.org/ticket/7377
<ul>
<li><strong>attachment</strong>
set to <em>trac_7377-fastcalculus_p2.patch</em>
</li>
</ul>
<p>
Patch based on Sage 4.6.2.alpha4, ECL 11.1.1 and Maxima 5.23.1, apply 3
</p>
TicketjpfloriTue, 15 Feb 2011 17:07:51 GMTattachment set
https://trac.sagemath.org/ticket/7377
https://trac.sagemath.org/ticket/7377
<ul>
<li><strong>attachment</strong>
set to <em>trac_7377-better-ask-error_p2.patch</em>
</li>
</ul>
<p>
Patch based on Sage 4.6.2.alpha4, ECL 11.1.1 and Maxima 5.23.1, apply 4
</p>
TicketkcrismanTue, 15 Feb 2011 17:16:11 GMT
https://trac.sagemath.org/ticket/7377#comment:58
https://trac.sagemath.org/ticket/7377#comment:58
<blockquote class="citation">
<p>
The best idea I got so far is to split all the non-pexpect and non-communication things of Sage pexpect class into a parent class and make <a class="missing wiki">MaximaAbstract?</a> inherit from that class so that we still have access to all the nice features defined in Pexpect class.
</p>
</blockquote>
<p>
Yes, we want to make sure that we can still use Maxima via the console as before, with all the usual stuff. I don't know exactly the best way to do that, but we definitely want that.
</p>
TicketjpfloriWed, 16 Feb 2011 09:17:03 GMT
https://trac.sagemath.org/ticket/7377#comment:59
https://trac.sagemath.org/ticket/7377#comment:59
<p>
Here is the list of the failure left in "make ptest" with all "_p2" patches applied:
</p>
<pre class="wiki">The following tests failed:
sage -t -force_lib devel/sage/sage/symbolic/assumptions.py # 2 doctests failed
sage -t -force_lib devel/sage/sage/symbolic/function_factory.py # 3 doctests failed
sage -t -force_lib devel/sage/sage/symbolic/expression.pyx # 1 doctests failed
sage -t -force_lib devel/sage/sage/symbolic/integration/integral.py # 5 doctests failed
sage -t -force_lib devel/sage/sage/interfaces/maxima_lib.py # 0 doctests failed
sage -t -force_lib devel/sage/sage/interfaces/maxima.py # 2 doctests failed
sage -t -force_lib devel/sage/sage/calculus/tests.py # 4 doctests failed
sage -t -force_lib devel/sage/sage/calculus/wester.py # 1 doctests failed
sage -t -force_lib devel/sage/sage/calculus/calculus.py # 2 doctests failed
sage -t -force_lib devel/sage/sage/calculus/desolvers.py # 7 doctests failed
sage -t -force_lib devel/sage/sage/calculus/functional.py # 1 doctests failed
sage -t -force_lib devel/sage/sage/structure/sage_object.pyx # 1 doctests failed
</pre><ol><li>symbolic/assumptions.py : Error reporting changed (RuntimeError ...)
</li><li>symbolic/function_factory.py : "del" thing as posted earlier
</li><li>symbolic/expression.pyx : got "x*log(9)" instead of "log(9^x)" so Maxima got better in simplify_all, but also a lot of blabbering : "solve: using arc-trig functions to get a solution.<br />Some solutions will be lost." and "rat: replaced -0.032 by -4/125 = -0.032"<br />
</li><li>symbolic/integration/integral.py : error reporting, numerical noise and same kind of verbosity as mentionned above ("rat: replaced ...")
</li><li>interfaces/maxima_lib.py : TAB character (anyway changes are still missing)
</li><li>interfaces/maxima.py : Error reporting
</li><li>calculus/tests.py :<br />
<ul><li>integrate(ceil(x^2 + floor(x)), x, 0, 5) gives 155/3 instead of integrate(ceil(x^2) + floor(x), x, 0, 5), Maple gives me 145
</li><li>integrate(sin(x), x, a, b) gives cos(a) - cos(b) instead of ceil(cos(a)) ...
</li><li>next 2 errors are __call__() takes at most 3 arguments (4 given)
</li></ul></li><li>calculus/wester.py : some verbosity ("solve:..."), the results are printed differently but are equal (I'll test with <a class="closed ticket" href="https://trac.sagemath.org/ticket/9880" title="defect: Pynac comparison functions do not provide a SWO (closed: fixed)">#9880</a>)
</li><li>calculus/calculus.py : <br />
<ul><li>a = sage.calculus.calculus.maxima("x#0"); a gives x # 0 and a lot of strange verbosity ("<strong>*JOB ABORT DUE TO UNRECOVERED ERROR.") instead of x<a class="missing ticket">#0</a>
</strong></li><li>nintegral reports error differently
</li></ul></li><li>calculus/desolvers.py : seems broken, lots of ascii art displayed things
</li><li>calculus/functional.py : error reporting
</li><li>structure/sage_object.pyx : unpickle failure: load('/home/jp/.sage/temp/napoleon/8057/dir_2/pickle_jar/_class__sage_interfaces_maxima_MaximaFunction__.sobj')
</li></ol><p>
So I get the same errors as reported above. I don't know why Maxima gets so verbose ("rat:...", "solve:...", ascii art things in desolve, "-- an error. To debug this try debugmode(true);"...), was it intended in the patches ?
</p>
<p>
Cheers,
</p>
TicketfbisseyWed, 16 Feb 2011 10:22:23 GMT
https://trac.sagemath.org/ticket/7377#comment:60
https://trac.sagemath.org/ticket/7377#comment:60
<p>
My experience is totally different. I patched my sage-on-gentoo to the max (ecl/maxima/cython/mpmath/ppl+this set), reinstall ecl-11.1.1, maxima-5.23.2 and sage-4.6.2.alpha4 and ran the tests.
</p>
<p>
The only abnormal failure for sage-on-gentoo was interfaces/r.py and it didn't show up again when I tried it individually. No SIGFPE, everything fine.
This is a 64 bit intel machine and the install of the sage spkg itself was from scratch.
</p>
<p>
It's the first time this patch set doesn't give me a huge amount of broken doctests back.
</p>
TicketnbruinWed, 16 Feb 2011 17:52:11 GMT
https://trac.sagemath.org/ticket/7377#comment:61
https://trac.sagemath.org/ticket/7377#comment:61
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/7377#comment:59" title="Comment 59">jpflori</a>:
</p>
<blockquote class="citation">
<p>
So I get the same errors as reported above. I don't know why Maxima gets so verbose ("rat:...", "solve:...", ascii art things in desolve, "-- an error. To debug this try debugmode(true);"...), was it intended in the patches ?
</p>
</blockquote>
<p>
That's wonderful! A cleaner refactoring as proposed above would be great. Concerning the verbosity: Maxima is always like that. With the current interface, pexpect receives this and filters it out. With the library setup, we're not listening to stdout anymore, so this ends up with the user. Possible solutions:
</p>
<ul><li>get maxima patched to have options to remove these warnings & verbosity. There are already a few out there (no error message is printed anymore thanks to turning one off), but others survive (the " -- an error occurred ..." is hard-wired. I've reported that one to Maxima)
</li></ul><ul><li>live with it (that shouldn't be necessary)
</li></ul><ul><li>redirect lisp standard output. Thankfully, lisp wraps all its I/O in its own stream system which allows for redirection so if we feed (setf *standard-output* *dev-null*) to ECL during maxima initialization, we'll never see anything (obviously not a good idea for debugging). Perhaps we also need that on *standard-error*. In fact, since a lot of this output does not seem to affect doctesting, perhaps it's already ending up on stderr.
</li></ul><p>
This actually suggests another approach to getting a strings-based interface to maxima/ECLlib:
</p>
<ul><li>locate the Maxima <a class="missing wiki">Read/Evaluate/Print?</a> loop and break it open to just be a <a class="missing wiki">Read/Evaluate/Print?</a> routine maxima-rep (i.e., it returns instead of looping)
</li><li>wrap this routine:
<pre class="wiki">(defun mrep-with-stringio (maxima-input-string)
(let ((*standard-input* (make-string-input-stream maxima-input-string))
(*standard-output* (make-string-output-stream)))
(maxima-rep)
(get-output-stream-string *standard-output*)
))
</pre></li></ul><p>
This approach would be a little closer to the current pexpect interface, so you could possibly reuse more of the current maxima pexpect interface. You'd still only be communicating with maxima via string I/O, though, whereas we can do much better with the library. It would be an option if all you're interested in is creating an I/O based interface to maxima without fork.
</p>
TicketfbisseyWed, 16 Feb 2011 18:42:50 GMT
https://trac.sagemath.org/ticket/7377#comment:62
https://trac.sagemath.org/ticket/7377#comment:62
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/7377#comment:60" title="Comment 60">fbissey</a>:
</p>
<blockquote class="citation">
<p>
My experience is totally different. I patched my sage-on-gentoo to the max (ecl/maxima/cython/mpmath/ppl+this set), reinstall ecl-11.1.1, maxima-5.23.2 and sage-4.6.2.alpha4 and ran the tests.
</p>
<p>
The only abnormal failure for sage-on-gentoo was interfaces/r.py and it didn't show up again when I tried it individually. No SIGFPE, everything fine.
This is a 64 bit intel machine and the install of the sage spkg itself was from scratch.
</p>
<p>
It's the first time this patch set doesn't give me a huge amount of broken doctests back.
</p>
</blockquote>
<p>
Dear me. I should have a curfew. I hadn't applied the maximalib patch after all. :(
</p>
TicketfbisseyWed, 16 Feb 2011 21:48:24 GMT
https://trac.sagemath.org/ticket/7377#comment:63
https://trac.sagemath.org/ticket/7377#comment:63
<p>
I get the same thing that Jean-Pierre in the end. But the SIGFPE I had before are gone. For some tests it is indeed just a matter of change in error reporting and we could just fix the doctests. I notice that sage/interfaces/maxima.py and sage/symbolic/integration/integral.py have a test in common:"integral(x^n,x)"
I also got an ecl error already mentioned
</p>
<pre class="wiki">File "/usr/share/sage/devel/sage-main/sage/libs/ecl.pyx", line 415:
sage: a
Expected:
<ECL: 9.999999999999999E39>
Got:
<ECL: 9.999999999999999e39>
</pre><p>
</p>
TicketjpfloriThu, 17 Feb 2011 18:15:46 GMT
https://trac.sagemath.org/ticket/7377#comment:64
https://trac.sagemath.org/ticket/7377#comment:64
<p>
I've put a first (very) rough version of a patch to refactor the different interfaces:
</p>
<ul><li>It split the previous Expect classes in Interface classes (without pexpect stuff, did not find a better name) and Expect classes (inheriting from the previous ones + pexpect stuff)
</li><li><a class="missing wiki">MaximaAbstract?</a> classes depends on Interface classes
</li><li><a class="missing wiki">MaximaLib?</a> on <a class="missing wiki">MaximaAbstract?</a>
</li><li>Maxima (classic) on <a class="missing wiki">MaximaAbstract?</a> and Expect
</li></ul><p>
It kind of works easily thanks to the current Method Resolution Order used by the version of Python in Sage but it obviously introduces a lot of new failures in addition to the one above.
</p>
<p>
The patch must be applied after the "_p2" patches (and ecl_iter).
</p>
<p>
It is quite big, touches a lot of files, and should be splitted in at least two parts (split Expect; refactor).
</p>
<p>
It is absolutely not considered as finished (very far from it) and I did not test it (apart from trivial things like integrate(x)), it is mainly to get some feedback on the choices I made, so any comments are mare than welcome.
</p>
TicketdrkirkbyThu, 17 Feb 2011 18:38:07 GMT
https://trac.sagemath.org/ticket/7377#comment:65
https://trac.sagemath.org/ticket/7377#comment:65
<p>
You should probably be aware of <a class="closed ticket" href="https://trac.sagemath.org/ticket/10766" title="defect: Update ECL to the latest upstream release. (closed: fixed)">#10766</a> (an update of ECL), which has positive review and <a class="closed ticket" href="https://trac.sagemath.org/ticket/10773" title="enhancement: Update Maxima to the latest upstream release. (closed: fixed)">#10773</a> (an update of Maxima) which also has positive review.
</p>
<p>
Dave
</p>
TicketkcrismanThu, 17 Feb 2011 18:45:55 GMT
https://trac.sagemath.org/ticket/7377#comment:66
https://trac.sagemath.org/ticket/7377#comment:66
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/7377#comment:65" title="Comment 65">drkirkby</a>:
</p>
<blockquote class="citation">
<p>
You should probably be aware of <a class="closed ticket" href="https://trac.sagemath.org/ticket/10766" title="defect: Update ECL to the latest upstream release. (closed: fixed)">#10766</a> (an update of ECL), which has positive review and <a class="closed ticket" href="https://trac.sagemath.org/ticket/10773" title="enhancement: Update Maxima to the latest upstream release. (closed: fixed)">#10773</a> (an update of Maxima) which also has positive review.
</p>
</blockquote>
<p>
If you look at the descriptions of the <code>p2</code> patches, they all mention they depend on those new versions, though not by ticket number. I think they are based on Maxima 5.23.1 it says, but probably that is not 100% necessary.
</p>
TicketnbruinThu, 17 Feb 2011 20:58:29 GMT
https://trac.sagemath.org/ticket/7377#comment:67
https://trac.sagemath.org/ticket/7377#comment:67
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/7377#comment:64" title="Comment 64">jpflori</a>:
</p>
<blockquote class="citation">
<p>
It kind of works easily thanks to the current Method Resolution Order used by the version of Python in Sage but it obviously introduces a lot of new failures in addition to the one above.
</p>
</blockquote>
<p>
Perhaps you can do a quick test if depending on multiple inheritance causes a huge slowdown in method resolution? (I guess that is the only major architectural change you're making). Since it's the *proper* thing to do even a small slowdown should be acceptable, but we wouldn't want to degrade too badly.
</p>
<blockquote class="citation">
<p>
The patch must be applied after the "_p2" patches (and ecl_iter).
</p>
</blockquote>
<p>
I recommend that you first do the refactoring *without* fast-calculus. That basically takes maxima_lib out of the equation and means you'll be refactoring code that is known to be good (actually, a quick test seems to indicate that the pexpect maxima interface based on abstract_maxima already breaks doctests. I think that back in 4.1.* or whatever Robert's work was based on, they were fine, so there may be some changes that didn't properly get adapted for the _p2 patches).
</p>
<p>
Perhaps open a separate ticket "refactor maxima to multiply inherit from a new class maxima_abstract and pexpect". It would reduce the number of complicating factors you'd be considering.
</p>
<p>
Work here would basically remain exploratory until that ticket is finished. We can then rebase the work here to your new organization of maxima interfaces. I noticed that your changes to maxima_lib.py were minimal so at least for now, that should be easy.
</p>
TicketjpfloriFri, 18 Feb 2011 16:40:08 GMT
https://trac.sagemath.org/ticket/7377#comment:68
https://trac.sagemath.org/ticket/7377#comment:68
<p>
Ok I found the reason of the strange "ceil" function appearing.
</p>
<p>
That's because sr_to_max calls op_max=caar(maxima(expr).ecl()) and maxima(expr) can simplify the object change its structure, so the dictionary is wrongly built (we get "ceil" for "+").
</p>
<p>
Putting op_max=maxima(op).ecl() seems functional.
</p>
<p>
The issue with (log(9)*x).simplify_log('all') is similar.
</p>
<p>
Maxima transforms log(9^x) back to log(9)*x before it is passed to string function in max_to_string:
</p>
<pre class="wiki">(%i8) logexpand:false$
(%i9) string(log(9^x));
(%o9) "log(9)*x"
(%i10) log(9^x);
(%o10) log(9)*x
(%i11) simp:false$
(%i12) log(9^x);
(%o12) log(9^x)
(%i13) string(log(9^x));
(%o13) "log(9^x)"
</pre><p>
As far as the classic pexpect interface is concerned, a lot of problems are solved if one changes "back" return result to return result._sage_() in sage.symbolic.integration.external
</p>
<p>
It used to be return result.sage() but some routines in the fastcalculus patch for maxlib return symbolic object which do not have such a method but one with underscores.
</p>
<p>
I'll post updated patches when they are in a better shape.
</p>
TicketnbruinFri, 18 Feb 2011 17:50:39 GMT
https://trac.sagemath.org/ticket/7377#comment:69
https://trac.sagemath.org/ticket/7377#comment:69
<p>
First of all, great sleuthing! Excellent progress.
</p>
<blockquote class="citation">
<p>
Ok I found the reason of the strange "ceil" function appearing.
</p>
<p>
That's because sr_to_max calls op_max=caar(maxima(expr).ecl()) and maxima(expr) can simplify the object change its structure, so the dictionary is wrongly built (we get "ceil" for "+").
</p>
<p>
Putting op_max=maxima(op).ecl() seems functional.
</p>
</blockquote>
<p>
I think I tried your alternative before, but that could also lead to parse errors (feeding just the operator to maxima may not lead to a syntactical expression on the other side). Note that the "learning" via the strings-based interface is only a hack to profit from work done there (and to stay compatible with it). Most of this knowledge on how to map SR.operator() objects to maxima and back, is hand-coded somewhere in sage anyway. If we could get that info once and for all and transcribe it to the sr_to_max dicts, we wouldn't need this hack anymore.
</p>
<blockquote class="citation">
<p>
The issue with (log(9)*x).simplify_log('all') is similar.
</p>
<p>
Maxima transforms log(9^x) back to log(9)*x before it is passed to string function in max_to_string:
</p>
</blockquote>
<p>
Interesting! So this problem would disappear again if simplify_log were wrapped similarly to sr_integral etc., where sr_to_max and max_to_sr are used as much as possible.
</p>
TicketnbruinFri, 18 Feb 2011 21:44:36 GMT
https://trac.sagemath.org/ticket/7377#comment:70
https://trac.sagemath.org/ticket/7377#comment:70
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/7377#comment:68" title="Comment 68">jpflori</a>:
</p>
<blockquote class="citation">
<p>
Maxima transforms log(9^x) back to log(9)*x before it is passed to string function in max_to_string:
</p>
</blockquote>
<p>
Thanks for locating the error! It's simply that maxima's <code>string</code> (in lisp <code>$STRING</code>) does too much work, meaning that max_to_string involves a new call to MEVAL. The definition is in <code>suprv1.lisp</code> and points to what to do differently. Two definitions in maxima_lib.py need adjusting:
</p>
<pre class="wiki">maxprint=EclObject("(defun mstring-for-sage (form) (coerce (mstring form) 'string))").eval()
def max_to_string(s):
return maxprint(s).python()[1:-1]
</pre><p>
WARNING: the routine maxprint is lisp, not maxima and is presently not run under maxima-eval's control, so maxima errors will be poorly reported. If converting maxima expressions to strings can trigger errors we need an adjusted version of maxima-eval that calls EVAL rather than MEVAL on the parameter (to execute lisp code under our replacement of maxima's toplevel)
</p>
TicketnbruinSat, 19 Feb 2011 04:02:35 GMT
https://trac.sagemath.org/ticket/7377#comment:71
https://trac.sagemath.org/ticket/7377#comment:71
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/7377#comment:68" title="Comment 68">jpflori</a>:
</p>
<blockquote class="citation">
<p>
That's because sr_to_max calls op_max=caar(maxima(expr).ecl()) and maxima(expr) can simplify the object change its structure, so the dictionary is wrongly built (we get "ceil" for "+").
</p>
<p>
Putting op_max=maxima(op).ecl() seems functional.
</p>
</blockquote>
<p>
A little digging gives us a way to access *just* the maxima reader, without the extra evaluation:
</p>
<pre class="wiki">mymread=ecl_eval("""
(defun my-mread (cmd)
(caddr (mread (make-string-input-stream cmd))))
""")
def parsemaxstring(l):
return mymread('"%s;"'%l)
</pre><p>
Examples:
</p>
<pre class="wiki">sage: parsemaxstring("integral(x^2,x)")
<ECL: (($INTEGRAL) ((MEXPT) $X 2) $X)>
sage: parsemaxstring("ceiling(x^2+floor(x))")
<ECL: (($CEILING) ((MPLUS) ((MEXPT) $X 2) (($FLOOR) $X)))>
sage: parsemaxstring("log(9^x)")
<ECL: ((%LOG) ((MEXPT) 9 $X))>
</pre><p>
The effect is about the same as
</p>
<pre class="wiki">sage: EclObject("#$ceiling(x^2+floor(x))$").cdr().car().cdr().car()
<ECL: (($CEILING) ((MPLUS) ((MEXPT) $X 2) (($FLOOR) $X)))>
</pre>
TicketjpfloriSun, 20 Feb 2011 20:57:50 GMT
https://trac.sagemath.org/ticket/7377#comment:72
https://trac.sagemath.org/ticket/7377#comment:72
<p>
With the new version of the patch only the following errors persist with maxima as a lib:
</p>
<ul><li>unpickling problems,
</li><li>some timeouts (sage.interfaces.gap3).
</li></ul><p>
And trivial to fix:
</p>
<ul><li>error reporting,
</li><li>floating point precision.
</li></ul><p>
With the classical maxima, I only get the first set of errors.
</p>
<p>
The translation of the derivatives seems better than before and the errors in desolver disappeared.
</p>
TicketjpfloriSun, 20 Feb 2011 20:58:41 GMTattachment set
https://trac.sagemath.org/ticket/7377
https://trac.sagemath.org/ticket/7377
<ul>
<li><strong>attachment</strong>
set to <em>trac_7377-split_and_refactor.patch</em>
</li>
</ul>
<p>
Version 0.2
</p>
TicketnbruinMon, 21 Feb 2011 03:55:09 GMT
https://trac.sagemath.org/ticket/7377#comment:73
https://trac.sagemath.org/ticket/7377#comment:73
<p>
Great work! The patches don't apply on 4.6.1 so I can't test them at the moment. Reading through the patch:
</p>
<ul><li>Line 74
<pre class="wiki"> (string-trim '(#\Newline) (with-output-to-string (*standard-output*)
(terpri)
</pre></li></ul><p>
If you're going to trim the newlines, don't bother with terpri. It just inserts a newline. Perhaps if you delete the terpri the trimming isn't necessary (I put it there because previously, the "ask" error messages had a newline before the question)
</p>
<ul><li>derivatives: If you want FDerivativeOperator handled by special_sage_to_max you'll need to change a bit more than just the API of the functions in that dictionary (for that, you can just put "op" as the first parameter and not use it in most cases)
</li></ul><p>
One possibility is to index special_sage_to_max by type(op) rather than op. Then it makes a lot more sense to pass op as a parameter too (because currently, the op would be a constant for any entry in special_sage_to_max).
</p>
<ul><li>the line:
<pre class="wiki">[deriv_max.extend([sr_to_max(args[i]), EclObject(params.count(i))]) for i in set(params)]
</pre></li></ul><p>
leads to an algorithm that is quadratic in the number of variables, but it should be (soft) linear. It should be interesting to design an example where this matters ...)
</p>
TicketjpfloriMon, 21 Feb 2011 09:04:08 GMT
https://trac.sagemath.org/ticket/7377#comment:74
https://trac.sagemath.org/ticket/7377#comment:74
<p>
There is currently a problem with ecl and signals.
</p>
<p>
With the current initialization, interrupting a computation does not work well.
</p>
<p>
You can try the example of sage.interfaces.maxima with maxima as a lib:
</p>
<pre class="wiki">sage: from sage.interfaces.maxima_lib import maxima_lib as maxlib
sage: maxlib('sum(1/x^2, x, 1, 10000)') # or bigger to be convinced
</pre><p>
and hit Ctrl+C immediately.
</p>
TicketnbruinMon, 21 Feb 2011 09:57:01 GMT
https://trac.sagemath.org/ticket/7377#comment:75
https://trac.sagemath.org/ticket/7377#comment:75
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/7377#comment:74" title="Comment 74">jpflori</a>:
</p>
<blockquote class="citation">
<p>
There is currently a problem with ecl and signals.
</p>
</blockquote>
<p>
Yes, sage.lib.ecl simply does not enable them.
</p>
<p>
It looks like ECL development has carefully looked at how to best handle signals. See <a class="ext-link" href="http://ecls.sourceforge.net/new-manual/ch22.html"><span class="icon"></span>http://ecls.sourceforge.net/new-manual/ch22.html</a> . But it also looks like a non-trivial task to adapt Sage's signal handling to play nice with the way ECL expects it. The ECL_OPT_SIGNAL_HANDLING_THREAD way sounds patently incompatible with sage.
</p>
<p>
You could of course try to just insert the appropriate sig_on() and sig_off() around the calls to ecl's "eval" and hope for the best. This must be a problem that has arisen for other libraries, such as pari, singular, ginac, gap etc.
</p>
TicketnbruinMon, 21 Feb 2011 22:39:47 GMT
https://trac.sagemath.org/ticket/7377#comment:76
https://trac.sagemath.org/ticket/7377#comment:76
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/7377#comment:74" title="Comment 74">jpflori</a>:
</p>
<blockquote class="citation">
<p>
There is currently a problem with ecl and signals.
</p>
</blockquote>
<p>
This is now <a class="closed ticket" href="https://trac.sagemath.org/ticket/10818" title="defect: EclLib should allow signals to make LISP code interruptable (closed: fixed)">#10818</a> . It has a rudimentary patch which seems to work, but I'm confident it can break badly. Also note that leaving ECL in a consistent state does not mean that Maxima is also left in a consistent state.
</p>
TicketnbruinFri, 25 Feb 2011 22:56:24 GMT
https://trac.sagemath.org/ticket/7377#comment:77
https://trac.sagemath.org/ticket/7377#comment:77
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/7377#comment:76" title="Comment 76">nbruin</a>:
</p>
<blockquote class="citation">
<p>
This is now <a class="closed ticket" href="https://trac.sagemath.org/ticket/10818" title="defect: EclLib should allow signals to make LISP code interruptable (closed: fixed)">#10818</a>
</p>
</blockquote>
<p>
This has now something that should be fairly robust.
</p>
TicketnbruinSun, 27 Feb 2011 02:56:36 GMT
https://trac.sagemath.org/ticket/7377#comment:78
https://trac.sagemath.org/ticket/7377#comment:78
<p>
I have tested the new packages with 4.6.2.alpha4 and I am finding largely agreement with JP. As a baseline, I have used ECL and Maxima from <a class="closed ticket" href="https://trac.sagemath.org/ticket/10766" title="defect: Update ECL to the latest upstream release. (closed: fixed)">#10766</a> and <a class="closed ticket" href="https://trac.sagemath.org/ticket/10773" title="enhancement: Update Maxima to the latest upstream release. (closed: fixed)">#10773</a> respectively, with applied patches:
</p>
<pre class="wiki">trac_10766-fix_doctest.patch
trac_10766-fix_symbolic_integration_integral.patch
trac_10773-fix_maxima_version.patch
trac_10743-ecl-iter_p1.patch
handlerswap.p2.patch #this is from ticket #10818
</pre><p>
All doctests are OK there. When I further apply
</p>
<pre class="wiki">trac_7377-abstract-maxima_p2.patch
trac_7377-maximalib_p2.patch
trac_7377-fastcalculus_p2.patch
trac_7377-better-ask-error_p2.patch
trac_7377-split_and_refactor.patch
</pre><p>
I am finding doctest failures that are just due to different errors reporting and floating point, so these can be fixed by changing the doctests:
</p>
<pre class="wiki">sage -t devel/sage-main/sage/calculus/functional.py # 1 doctests failed
sage -t devel/sage-main/sage/interfaces/maxima.py # 2 doctests failed
sage -t devel/sage-main/sage/symbolic/assumptions.py # 2 doctests failed
sage -t devel/sage-main/sage/symbolic/integration/integral.py # 5 doctests failed
</pre><p>
Furthermore,
</p>
<pre class="wiki">sage -t devel/sage-main/sage/tests/startup.py # 1 doctests failed
</pre><p>
usually fails. Note that we are now initializing ECL upon startup, so we're really doing more work. Should we be lazy with this? This just means that the calculus maxima instance would have to be made lazy (i.e., set to a function that initializes maxima and then rebinds sage.calculus.maxima)
</p>
<pre class="wiki">sage -t devel/sage-main/sage/structure/sage_object.pyx # 1 doctests failed
</pre><p>
needs a pickling expert
</p>
<pre class="wiki">sage -t devel/sage-main/sage/interfaces/gap3.py # Time out
</pre><p>
this is a real error that was probably introduced by <code>split_and_refactor</code>. The timeout is caused by an infinite recursion upon exit (run with -verbose) and probably has to do with the fact that
</p>
<pre class="wiki">sage: gap3("1+2")
</pre><p>
now fails differently. It seems that a "name()" attribute is missing. If you now try to "quit()", an infinite loop on some Exception resolution is triggered, but I expect the damage happened in the line above. gap3 is optional, by the way, but the error apparently already happens with tests that check the absence of gap3.
</p>
<p>
Impressive progress indeed!
</p>
TicketnbruinSun, 27 Feb 2011 03:45:32 GMTattachment set
https://trac.sagemath.org/ticket/7377
https://trac.sagemath.org/ticket/7377
<ul>
<li><strong>attachment</strong>
set to <em>trac_7377-lazy-maxlib.patch</em>
</li>
</ul>
<p>
Improves startup time by lazily loading maxima_lib in calculus
</p>
TicketjpfloriSun, 27 Feb 2011 11:39:40 GMT
https://trac.sagemath.org/ticket/7377#comment:79
https://trac.sagemath.org/ticket/7377#comment:79
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/7377#comment:78" title="Comment 78">nbruin</a>:
</p>
<blockquote class="citation">
<p>
<code> sage -t devel/sage-main/sage/interfaces/gap3.py # Time out </code> this is a real error that was probably introduced by <code>split_and_refactor</code>. The timeout is caused by an infinite recursion upon exit (run with -verbose) and probably has to do with the fact that <code> sage: gap3("1+2") </code> now fails differently. It seems that a "name()" attribute is missing. If you now try to "quit()", an infinite loop on some Exception resolution is triggered, but I expect the damage happened in the line above. gap3 is optional, by the way, but the error apparently already happens with tests that check the absence of gap3. Impressive progress indeed!
</p>
</blockquote>
<p>
Thanks for that one, I do not have gap3 installed and get the time out, but did not bother. I'll have a look at it.
</p>
TicketnbruinSun, 27 Feb 2011 19:09:05 GMTattachment set
https://trac.sagemath.org/ticket/7377
https://trac.sagemath.org/ticket/7377
<ul>
<li><strong>attachment</strong>
set to <em>trac_7377-interface-namefix.patch</em>
</li>
</ul>
<p>
Fixes gap3 timeout problem
</p>
TicketnbruinSun, 27 Feb 2011 19:15:48 GMT
https://trac.sagemath.org/ticket/7377#comment:80
https://trac.sagemath.org/ticket/7377#comment:80
<p>
The benefits of unexpected snow ... It looks like the gap3 problem was due to some unqualified references to <code>name()</code> in sage.interfaces.interface, where it should be <code>self.name()</code>. Patch attached, but since this was a rather low-brained search-and-replace, JP should check I didn't miss any/didn't change any erroneously.
</p>
<p>
The one pickling problem is the only issue left!
</p>
TicketnbruinTue, 01 Mar 2011 09:06:36 GMT
https://trac.sagemath.org/ticket/7377#comment:81
https://trac.sagemath.org/ticket/7377#comment:81
<p>
Some forensics on:
</p>
<pre class="wiki">sage -t devel/sage-main/sage/structure/sage_object.pyx
</pre><p>
The error occurs on
<code>_class__sage_interfaces_maxima_MaximaFunction__.sobj</code> in the pickle jar, coming from the doctest (slightly adapted):
</p>
<pre class="wiki">sage: f=maxima.function('x,y','sin(x+y)')
sage: save(f,"newpickle.sobj")
sage: load("newpickle.sobj")==f
True
</pre><p>
The incompatibility seems to come from a rearranging of the abstract_maxima interface etc.
To pin down version information:
</p>
<pre class="wiki">$ ls -l _class__sage_interfaces_maxima_MaximaFunction__.*
-rw-r--r-- 1 nbruin nbruin 96 2009-03-10 13:04 _class__sage_interfaces_maxima_MaximaFunction__.sobj
-rw-r--r-- 1 nbruin nbruin 130 2009-03-10 13:04 _class__sage_interfaces_maxima_MaximaFunction__.txt
$ cat _class__sage_interfaces_maxima_MaximaFunction__.txt
type(obj) = <class 'sage.interfaces.maxima.MaximaFunction'>
version = 3.4.rc1
obj =
' sage270'
</pre><p>
Loading this pickle into a new version yields:
</p>
<pre class="wiki">sage: load("/home/nbruin/_class__sage_interfaces_maxima_MaximaFunction__.sobj");
AttributeError: 'module' object has no attribute 'reduce_load_Maxima_function'
</pre><p>
On the other hand, loading the new pickle into an old version (4.3.4):
</p>
<pre class="wiki">sage: load("newpickle.sobj");
ImportError: No module named maxima_abstract
</pre><p>
So this seems to be not so much an error but more a non-compatible change. I am sure these have happened before elsewhere. I'd be happy to just accept the fact that these pickles aren't portable across these versions, but if someone has an example we might be able to put the hooks in to preserve backwards compatibility (really, no-one should have a reason to pickle maxima functions from sage).
</p>
TicketnbruinTue, 01 Mar 2011 09:18:55 GMTattachment set
https://trac.sagemath.org/ticket/7377
https://trac.sagemath.org/ticket/7377
<ul>
<li><strong>attachment</strong>
set to <em>trac_7377-pickle-fix.patch</em>
</li>
</ul>
<p>
Fixes <a class="missing wiki">MaximaFunction?</a> pickle issue
</p>
TicketjpfloriTue, 01 Mar 2011 09:21:37 GMT
https://trac.sagemath.org/ticket/7377#comment:82
https://trac.sagemath.org/ticket/7377#comment:82
<p>
Replying to <a class="ext-link" href="http://trac.sagemath.org/sage_trac/search/opensearch?q=comment%3A80"><span class="icon"></span>nbruin</a>:
</p>
<blockquote class="citation">
<p>
The benefits of unexpected snow ... It looks like the gap3 problem was due to some unqualified references to <code>name()</code> in sage.interfaces.interface, where it should be <code>self.name()</code>. Patch attached, but since this was a rather low-brained search-and-replace, JP should check I didn't miss any/didn't change any erroneously. The one pickling problem is the only issue left!
</p>
</blockquote>
<p>
Thanks for the fix, that was my mistake: I changed some references to self.__name to calls to a name() function which was much more clear with the new class hierarchy.
</p>
<p>
I confirm that your patch fixes the gap3 timeout (without gap3 installed).
</p>
<p>
I'll post an updated patch "split_and_refactor" including your fixes and some changes so that the name of "<a class="missing wiki">MaximaLib?</a>" is now "_maxima_lib_" (even if most of the time, if not always, the related objects are treated like maxima ones for now).
</p>
<p>
As far as the pickling problem is concerned, I was aware that it was "just" caused by the changes in class hierarchy (and names).
</p>
<p>
I search a little bit through Google (http://ask.sagemath.org/question/123/what-is-the-standard-pickle-jar-for-and-how-do-i), and I think the Sage general policy is to be able to pick up old pickles (quite lgical), so I guess that we should try to include a workaround.
</p>
<p>
...Ok you've just posted a fix for that one too, so I'll include it as well.
</p>
TicketnbruinTue, 01 Mar 2011 09:32:07 GMTdescription changed
https://trac.sagemath.org/ticket/7377#comment:83
https://trac.sagemath.org/ticket/7377#comment:83
<ul>
<li><strong>description</strong>
modified (<a href="/ticket/7377?action=diff&version=83">diff</a>)
</li>
</ul>
TicketfbisseyTue, 01 Mar 2011 09:48:28 GMT
https://trac.sagemath.org/ticket/7377#comment:84
https://trac.sagemath.org/ticket/7377#comment:84
<p>
That sounds great. Just to be picky could the split_and_refactor patch be consolidated? By that I mean that the patchset patch some files like sage/interfaces/expect.py and then patch over that patch. It makes things fairly difficult to follow from my point of view.
</p>
TicketjpfloriTue, 01 Mar 2011 09:57:58 GMT
https://trac.sagemath.org/ticket/7377#comment:85
https://trac.sagemath.org/ticket/7377#comment:85
<p>
I'm currently running "make ptestlong" to check for errors we could have missed.
</p>
<p>
As soon as it is finished (say in a couple of hours), I'll post a new version of "split_and_refactor" including the following patches:
</p>
<pre class="wiki">trac_7377-split_and_refactor.patch
trac_7377-interface-namefix.patch
trac_7377-pickle-fix.patch
</pre><p>
And a minor change I made inbetween which is in none of these patches (setting the "name" of maxima lib to "_maxima_lib_" rather than "_maxima_").
</p>
<p>
Is that what you wanted (there will still be successive patches applied to maxima* files... however) ?
</p>
TicketfbisseyTue, 01 Mar 2011 10:11:06 GMT
https://trac.sagemath.org/ticket/7377#comment:86
https://trac.sagemath.org/ticket/7377#comment:86
<p>
That's not what I meant Jean-Pierre. The current split_and_refactor patch starts with:
</p>
<pre class="wiki">diff -r a928dca2950b -r b766df9c3439 sage/interfaces/expect.py
--- a/sage/interfaces/expect.py Fri Feb 04 14:19:57 2011 -0800
+++ b/sage/interfaces/expect.py Mon Feb 14 14:06:15 2011 +0100
@@ -42,6 +42,8 @@
import time
</pre><p>
and some patching is done to that file. Then later in the same patch file file we have
</p>
<pre class="wiki"> from mupad import mupad, mupad_console, Mupad # NOT functional yet
diff -r b766df9c3439 -r fba59ed64da6 sage/interfaces/expect.py
--- a/sage/interfaces/expect.py Mon Feb 14 14:06:15 2011 +0100
+++ b/sage/interfaces/expect.py Wed Feb 16 16:38:39 2011 +0100
@@ -489,12 +489,6 @@
except Exception, msg:
</pre><p>
Which is applied on top of the previous one. sage/interfaces/maxima_lib.py
is also in that case and I am fairly sure there is a third one like that.
</p>
<p>
I am guessing the first set is the "split" part and the second "refactor". In short I would prefer if there was only one instance of patching these files rather than two in succession in the same patch. But as I said that's because I am being picky.
Mercurial seems to cope fine with those, gnu patch doesn't really like them.
</p>
TicketjpfloriTue, 01 Mar 2011 11:37:01 GMT
https://trac.sagemath.org/ticket/7377#comment:87
https://trac.sagemath.org/ticket/7377#comment:87
<p>
With the new patch that follows (and without lazy patch!), I only get the following failures due to error reporting and float precision:
</p>
<pre class="wiki">----------------------------------------------------------------------
The following tests failed:
sage -t -long -force_lib devel/sage/sage/interfaces/maxima.py # 2 doctests failed
sage -t -long -force_lib devel/sage/sage/calculus/functional.py # 1 doctests failed
sage -t -long -force_lib devel/sage/sage/symbolic/assumptions.py # 2 doctests failed
sage -t -long -force_lib devel/sage/sage/symbolic/integration/integral.py # 5 doctests failed
----------------------------------------------------------------------
Total time for all tests: 2633.7 seconds
</pre><p>
The update patch should be "consolidated" as asked (that was because of the command I used to generate it).
</p>
<p>
So the patches should be applied as follows:
</p>
<pre class="wiki">trac_7377-abstract-maxima_p2.patch
trac_7377-maximalib_p2.patch
trac_7377-fastcalculus_p2.patch
trac_7377-better-ask-error_p2.patch
trac_7377-split_and_refactor_p2.patch
</pre><p>
Applying "lazy" patch breaks more test for me:
</p>
<ul><li>lazy objects are not callable so maxima(x) fails in sage.plot.plot3d.plot3d
</li><li>exception raised in sage.plot.line
</li></ul>
TicketnbruinTue, 01 Mar 2011 18:19:25 GMT
https://trac.sagemath.org/ticket/7377#comment:88
https://trac.sagemath.org/ticket/7377#comment:88
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/7377#comment:87" title="Comment 87">jpflori</a>:
</p>
<blockquote class="citation">
<p>
Applying "lazy" patch breaks more test for me:
</p>
<ul><li>lazy objects are not callable so maxima(x) fails in sage.plot.plot3d.plot3d
</li><li>exception raised in sage.plot.line
</li></ul></blockquote>
<p>
Sorry and thanks for catching. Both are solved by adding a "<span class="underline">call</span>" method to lazy:
</p>
<pre class="wiki"> def __call__(self,*args,**kwargs):
import sage.interfaces.maxima_lib
sage.calculus.calculus.maxima = sage.interfaces.maxima_lib.maxima
return sage.calculus.calculus.maxima(*args,**kwargs)
</pre><p>
but in fact <code>sage.misc.lazy_import</code> does exactly what we need here. (See attached patch). I've ran doctests and I don't think the lazy causes additional fails.
</p>
<p>
Incidentally, I'm getting a silly doctest failure
</p>
<pre class="wiki">sage -t "devel/sage-main/sage/interfaces/maxima_abstract.py"
</pre><p>
for the result of
</p>
<pre class="wiki">sage: sorted(maxima._commands(verbose=False))
</pre><p>
but it looks like nothing has changed. Perhaps my build is corrupted.
</p>
TicketnbruinTue, 01 Mar 2011 18:20:22 GMTattachment set
https://trac.sagemath.org/ticket/7377
https://trac.sagemath.org/ticket/7377
<ul>
<li><strong>attachment</strong>
set to <em>trac_7377-lazy-maxlib.p2.patch</em>
</li>
</ul>
<p>
Lazy import of maxima in calculus using sage.misc.lazy_import
</p>
TicketnbruinTue, 01 Mar 2011 21:40:47 GMT
https://trac.sagemath.org/ticket/7377#comment:89
https://trac.sagemath.org/ticket/7377#comment:89
<p>
Turns out the rounding errors weren't really that. Rather, max_to_sr preferred to return floats rather than <a class="missing wiki">RealDoubleElement?</a>, which are apparently the sage default type for float, and these print differently:
</p>
<pre class="wiki">sage: var('x,y')
(x, y)
sage: assume(y>1)
sage: M=sage.calculus.calculus.maxima
sage: I1=SR(M("integrate(log(x^2+y^2),x,0.0001414,1.0)"))
sage: I2=integrate(log(x^2+y^2),x,0.0001414,1.0)
sage: c1=I1.operands()[2].operands()[1].pyobject()
sage: c2=I2.operands()[2].operands()[1].pyobject()
sage: [c1,c2]
[-0.0001414, -0.00014139999999999999]
sage: [type(c1),type(c2)]
[<type 'sage.rings.real_double.RealDoubleElement'>, <type 'float'>]
</pre><p>
Patch attached. That means that the <span class="underline">only</span> doctest failures now are due to the fact that "maxima asks a question" gets reported via a different error. Ready for review?
</p>
TicketnbruinTue, 01 Mar 2011 21:41:25 GMTattachment set
https://trac.sagemath.org/ticket/7377
https://trac.sagemath.org/ticket/7377
<ul>
<li><strong>attachment</strong>
set to <em>trac_7377-floatcast.patch</em>
</li>
</ul>
<p>
make max_to_sr return <a class="missing wiki">RealDoubleElement?</a> rather than float
</p>
TicketnbruinTue, 01 Mar 2011 21:52:22 GMTdescription changed
https://trac.sagemath.org/ticket/7377#comment:90
https://trac.sagemath.org/ticket/7377#comment:90
<ul>
<li><strong>description</strong>
modified (<a href="/ticket/7377?action=diff&version=90">diff</a>)
</li>
</ul>
TicketkcrismanWed, 02 Mar 2011 02:56:48 GMT
https://trac.sagemath.org/ticket/7377#comment:91
https://trac.sagemath.org/ticket/7377#comment:91
<blockquote class="citation">
<p>
Patch attached. That means that the <span class="underline">only</span> doctest failures now are due to the fact that "maxima asks a question" gets reported via a different error. Ready for review?
</p>
</blockquote>
<p>
I'm sorry I haven't been able to test this lately. Can you give an example? As long as the end user still knows what to do (as in, <code>assume(x>0)</code> etc.) that should be fine.
</p>
TicketjpfloriWed, 02 Mar 2011 09:21:32 GMT
https://trac.sagemath.org/ticket/7377#comment:92
https://trac.sagemath.org/ticket/7377#comment:92
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/7377#comment:91" title="Comment 91">kcrisman</a>:
</p>
<blockquote class="citation">
<blockquote class="citation">
<p>
Patch attached. That means that the <span class="underline">only</span> doctest failures now are due to the fact that "maxima asks a question" gets reported via a different error. Ready for review?
</p>
</blockquote>
<p>
I'm sorry I haven't been able to test this lately. Can you give an example? As long as the end user still knows what to do (as in, <code>assume(x>0)</code> etc.) that should be fine.
</p>
</blockquote>
<p>
For example:
</p>
<pre class="wiki"> sage: integral(x^n,x)
Expected:
Traceback (most recent call last):
...
TypeError: Computation failed since Maxima requested additional constraints (try the command 'assume(n+1>0)' before integral or limit evaluation, for example):
Is n+1 zero or nonzero?
Got:
Traceback (most recent call last):
...
RuntimeError: ECL says: Maxima asks: Is n+1 zero or nonzero?
</pre><p>
So we do not parse the error message and are less explicit than before.
</p>
<p>
There are still some things I'd like to change before a potential review:
</p>
<ol><li>Currently the interact function is broken for maxima_lib, it would be nicer to have it working than deleting it (and we should not leave something broken)
</li><li>I'll update "split_and_refactor" to get rid of superfluous terpri or string-trim as stated in comment 73
</li><li>Someone should check error stated in comment 88, I also got it sometimes, not sure why because that code was not so much touched
</li><li>I could merge "floatcast" with "fast_calulculus" or "split_and_refactor" so that we have less patches to apply and it is easier to test
</li><li>Parse error messages or just change the doctests and do bettor error reporting later.
</li></ol><p>
Afterwards (in other tickets ?):
</p>
<ol><li>Add doctests to maxima_abstract and maxima_lib
</li><li>Avoid as much as possible string conversion in maxima_lib and take into account comment 73.
</li></ol>
TicketjpfloriWed, 02 Mar 2011 09:54:26 GMT
https://trac.sagemath.org/ticket/7377#comment:93
https://trac.sagemath.org/ticket/7377#comment:93
<p>
Here is a patch to fix the interact function. It was only broken because python_to_ecl did not convert unicode objects.
</p>
<p>
My workaround is to convert the unicode object to an str object and convert that object as before.
</p>
<p>
There is surely a better way to do it, feel free to post a better patch and I'll integrate it to split_and_refactor instead of this one.
</p>
TicketjpfloriWed, 02 Mar 2011 09:55:14 GMTattachment set
https://trac.sagemath.org/ticket/7377
https://trac.sagemath.org/ticket/7377
<ul>
<li><strong>attachment</strong>
set to <em>trac_7377-unicode_to_ecl.patch</em>
</li>
</ul>
<p>
Convert unicode objects to str objects to build ecl objects.
</p>
TicketfbisseyWed, 02 Mar 2011 10:03:36 GMT
https://trac.sagemath.org/ticket/7377#comment:94
https://trac.sagemath.org/ticket/7377#comment:94
<p>
Does this patch means that sage won't be allergic to ecl being compiled with unicode support anymore?
<a class="ext-link" href="https://github.com/cschwan/sage-on-gentoo/issues/closed#issue/2"><span class="icon"></span>https://github.com/cschwan/sage-on-gentoo/issues/closed#issue/2</a>
</p>
TicketkcrismanWed, 02 Mar 2011 13:11:53 GMT
https://trac.sagemath.org/ticket/7377#comment:95
https://trac.sagemath.org/ticket/7377#comment:95
<p>
Thanks for indulging me, that helps a lot.
</p>
<blockquote class="citation">
<pre class="wiki"> sage: integral(x^n,x)
Expected:
Traceback (most recent call last):
...
TypeError: Computation failed since Maxima requested additional constraints (try the command 'assume(n+1>0)' before integral or limit evaluation, for example):
Is n+1 zero or nonzero?
Got:
Traceback (most recent call last):
...
RuntimeError: ECL says: Maxima asks: Is n+1 zero or nonzero?
</pre><p>
So we do not parse the error message and are less explicit than before.
</p>
</blockquote>
<p>
Hmm, we should really catch this particular <a class="missing wiki">RuntimeError?</a> (enough to search for 'Maxima asks', I think) and then copy the code which gave the user a potential way to fix it. This behavior will be too confusing for the most likely people to be using Maxima, which is why we changed it the first time. Should be pretty easy to copy from the previous behavior, though, if you are still getting this error.
</p>
TicketnbruinWed, 02 Mar 2011 18:23:42 GMT
https://trac.sagemath.org/ticket/7377#comment:96
https://trac.sagemath.org/ticket/7377#comment:96
<ul><li>Better organization of patches: Yes! Keep in mind that separate patches have served us well previously, though, when initial fixes were amended (e.g., lazy loading).
</li></ul><ul><li>unicode_to_ecl: seems like a reasonable approach to me. ECL can support unicode, but that is probably not of much use to us. Should that one go on a separate ticket, though? (think bitrot)
</li></ul><ul><li>doctest in <a class="ext-link" href="http://trac.sagemath.org/sage_trac/ticket/7377#comment:88"><span class="icon"></span>http://trac.sagemath.org/sage_trac/ticket/7377#comment:88</a> Perhaps the following helps. I tried that test on a pristine patched 4.6.2 and it passed. Then I ran <code>make ptestlong</code> and now it fails -- also when run individually. So that would point to ptestlong changing something. Does it rewrite/invalidate some maxima cache somewhere?
</li></ul><ul><li>errors: I realized I was not quite correct. Errors about inconsistent assumptions now get reported differently too.
</li></ul><ul><li>effort on error messages: Exceptions get used as a program flow control tool (e.g., in the coercion system) so any extra effort on constructing an error message has the potential of slowing down the system. So if you want extra info in the error message, put it where the string is created. We're controlling both sides of the plumbing anyway. See the better-ask-error patch. You could change it to something like
<pre class="wiki"> (cond ((not print?) ;;I'm not sure we want to honour this flag
(setq print? t)
(princ *prompt-prefix*) ;;and I'm not sure we care about pre/suffices either
(princ *prompt-suffix*))
((null msg)
(princ "nothing")
((atom msg)
(format t "~a~a~a" *prompt-prefix* msg *prompt-suffix*)
;;(format t "~a" msg ) ;;if we don't care about pre/suff
(mterpri))
((eq flag t)
(princ *prompt-prefix*)
(mapc #'princ (cdr msg))
(princ *prompt-suffix*)
(mterpri))
(t
(princ *prompt-prefix*)
(displa msg)
(princ *prompt-suffix*)
(mterpri))))))
(princ " You maybe able to answer this by using assume(...)")) ;;put helpful advice here
</pre></li></ul><ul><li>the same applies to the python_to_ecl error message: By using a "...%s..."%... in constructing the error message, you are slowing down the exception propagation. People can easily figure out which type it failed on by letting python drop into a debugger (%pdb 1) that allows them to analyze the local environment upon exception raising. (OK, you have to go "u" one time because pdb isn't terribly helpful with cython functions)
</li></ul><ul><li>ecl+unicode: I doubt this patch solves it, since this implements something that was previously properly signalled by an exception, whereas the bugreport deals with a timeout. I suspect that bug might come from something in the other direction: ECL producing unicode that <a class="missing wiki">EclObject?</a> doesn't know how to deal with. I am sure this failure originates from <span class="underline">me</span> being non-unicode compliant, since both ecl and python individually can handle this properly.
</li></ul>
TicketjpfloriWed, 02 Mar 2011 18:29:11 GMT
https://trac.sagemath.org/ticket/7377#comment:97
https://trac.sagemath.org/ticket/7377#comment:97
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/7377#comment:96" title="Comment 96">nbruin</a>:
</p>
<blockquote class="citation">
<ul><li>doctest in <a class="ext-link" href="http://trac.sagemath.org/sage_trac/ticket/7377#comment:88"><span class="icon"></span>http://trac.sagemath.org/sage_trac/ticket/7377#comment:88</a> Perhaps the following helps. I tried that test on a pristine patched 4.6.2 and it passed. Then I ran <code>make ptestlong</code> and now it fails -- also when run individually. So that would point to ptestlong changing something. Does it rewrite/invalidate some maxima cache somewhere?
</li></ul></blockquote>
<p>
It messes something in ~/.sage/maxima_commandlist_cache.sobj on my computer.
</p>
<p>
Did not took the time to investigate it further.
</p>
<p>
If you delete that file it runs again.
</p>
<blockquote class="citation">
<ul><li>errors: I realized I was not quite correct. Errors about inconsistent assumptions now get reported differently too.
</li></ul></blockquote>
<p>
I was aware of the inconsistent assumptions, I guess that's not a big problem.
</p>
<blockquote class="citation">
<ul><li>the same applies to the python_to_ecl error message: By using a "...%s..."%... in constructing the error message, you are slowing down the exception propagation. People can easily figure out which type it failed on by letting python drop into a debugger (%pdb 1) that allows them to analyze the local environment upon exception raising. (OK, you have to go "u" one time because pdb isn't terribly helpful with cython functions)
</li></ul></blockquote>
<p>
I'll remove it.
</p>
TicketkcrismanWed, 02 Mar 2011 19:31:47 GMT
https://trac.sagemath.org/ticket/7377#comment:98
https://trac.sagemath.org/ticket/7377#comment:98
<blockquote class="citation">
<ul><li>effort on error messages: Exceptions get used as a program flow control tool (e.g., in the coercion system) so any extra effort on constructing an error message has the potential of slowing down the system. So if you want extra info in the error message, put it where the string is created. We're controlling both sides of the plumbing anyway. See the better-ask-error patch. You could change it to something like
</li></ul></blockquote>
<pre class="wiki"> (princ " You maybe able to answer this by using assume(...)")) ;;put helpful advice here
</pre><p>
Yes, this would be ideal of course, it's just not something I know enough Lisp to do properly. Is there a way to format the returned message in a similar way to how it currently happens (so that your ellipses above are filled in)? It's currently something like
</p>
<pre class="wiki"> j = v.find('Is ')
v = v[j:]
k = v.find(' ',4)
msg = "Computation failed since Maxima requested additional constraints (try the command 'assume(" + v[4:k] +">0)' before integral or limit evaluation, for example):\n" + v + self._ask[i-1]
self._sendline(";")
</pre><p>
So if one could do the same extracting of the Of course, this is at the end of a long line of other things it does with respect to the <code>self._ask</code> business, which might be annoying. Still, anything which does not explicitly give a Sage command which has a chance to work would be a downgrade.
</p>
<p>
Otherwise amazing work, by the way! So cool to see this nearly done.
</p>
TicketnbruinWed, 02 Mar 2011 20:21:46 GMT
https://trac.sagemath.org/ticket/7377#comment:99
https://trac.sagemath.org/ticket/7377#comment:99
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/7377#comment:98" title="Comment 98">kcrisman</a>:
</p>
<blockquote class="citation">
<p>
Is there a way to format the returned message in a similar way to how it currently happens (so that your ellipses above are filled in)?
</p>
</blockquote>
<p>
Yes, you could do the string processing in lisp, but in that case you may want to intercept that various ask... routines to preformat the question that gets sent to retrieve to begin with. Those should have more structured information on what question is asked, so formatting the question differently there should be quite cheap. However, there are two points why I think it's a bad idea anyway:
</p>
<ul><li>The advice currently is wrong! Why would "...>0" be the right thing? That just propagates a kind of halfbrained trial-and-error mathematics that I cannot bring myself to endorse. The proper advice is for the user to read up on the assume(...) facility.
</li></ul><ul><li>There are big problems with relying on the print names of symbols agreeing between maxima and sage. Now that we're moving away from string-based communication it would be quite easy to let SR("x") correspond to <a class="missing wiki">EclObject?</a>("$SAGE-SYMBOLIC-VARIABLE-4711"). The actual question that maxima asks is not so enlightening anymore in that situation.
</li></ul><p>
In fact, currently, the advice already leads to errors
</p>
<pre class="wiki">sage: my_symbolic_n=SR.var('n')
sage: limit(x^my_symbolic_n,x=oo)
TypeError: Computation failed since Maxima requested additional constraints (try the command 'assume(n>0)' before integral or limit evaluation, for example):
Is n positive, negative, or zero?
sage: assume(n>0)
AttributeError: 'bool' object has no attribute 'assume'
sage: n
<function numerical_approx at 0x18e0410>
</pre><p>
so the user actually has a good reason to not shadow the python binding of n, but of course the print name n for a symbolic variable is very desirable. You CANNOT assume that the print name corresponds with the python variable bound to your object and sage SHOULD NOT propagate such assumptions in its error messages. It's nice to make a program accessible to starters but not at the expense of allowing them to progress to experienced users.
</p>
TicketkcrismanWed, 02 Mar 2011 21:16:48 GMT
https://trac.sagemath.org/ticket/7377#comment:100
https://trac.sagemath.org/ticket/7377#comment:100
<p>
</p>
<blockquote class="citation">
<ul><li>The advice currently is wrong! Why would "...>0" be the right thing? That just propagates a kind of halfbrained trial-and-error mathematics that I cannot bring myself to endorse. The proper advice is for the user to read up on the assume(...) facility.
</li></ul></blockquote>
<p>
Then you did not read the words, "for example". And the 'trial-and-error mathematics' comment may then be aimed at Maxima as well, especially when it asks all kinds of questions and the result is always the same. (rjf would no doubt comment that this is undecidable.) Perhaps the user really didn't consider whether <code>x>0</code> until just then, and might as well try all possibilities. That certainly happens in real life.
</p>
<p>
This is the best we have to deal with it right now, and until Maxima stops asking such questions, what else can one do? The error message gives the syntax, not the mathematics. Can you think of a different way to phrase it that makes it clear we aren't actually suggesting <code>x>0</code> in reality?
</p>
<p>
Saying to read up on assume() is sort of like telling people to read the man page; totally useless if you do not already have an idea that such a thing exists. Read <code>assume?</code> if you don't believe me. Obviously that could be improved, but it would be strange to put things about integrals and limits at the top of that file (where they'd need to be to catch attention), and there is no reason not to give a maximally helpful error message right off the bat.
</p>
<blockquote class="citation">
<blockquote>
<p>
In fact, currently, the advice already leads to errors
sage: my_symbolic_n=SR.var('n')
sage: limit(x<sup>my_symbolic_n,x=oo)
<a class="missing wiki">TypeError?</a>: Computation failed since Maxima requested additional constraints (try the command 'assume(n>0)' before integral or limit evaluation, for example):
Is n positive, negative, or zero?
sage: assume(n>0)
<a class="missing wiki">AttributeError?</a>: 'bool' object has no attribute 'assume'
sage: n
<function numerical_approx at 0x18e0410>
</sup></p>
</blockquote>
<p>
You CANNOT assume that the print name corresponds with the python variable bound to your object and sage SHOULD NOT propagate such assumptions in its error messages. It's nice to make a program accessible to starters but not at the expense of allowing them to progress to experienced users.
</p>
</blockquote>
<p>
Nothing here is stopping someone from advancing to being experienced. This problem occurs other places than here - see many discussions on sage-devel about print names not coinciding, or about var() being annoying in general. If someone knows anything about what you are saying, they will be plenty experienced to realize that this message isn't talking about 'their' n.
</p>
<p>
Sorry if I sound irked. But there is a place for such lawyering - lawyering over a minor thing which would make Sage more friendly to beginners and which doesn't actually harm the advanced users - and that place is not in a program that is trying to become a 'viable replacement for Mathematica and Maple'. I've seen this over and over, and can't figure out who this is hurting in many such cases.
</p>
<p>
Anyway, I hope we can come to some reasonable compromise on this. The current suggestion would make a very common error message less useful.
</p>
TicketnbruinWed, 02 Mar 2011 23:17:38 GMT
https://trac.sagemath.org/ticket/7377#comment:101
https://trac.sagemath.org/ticket/7377#comment:101
<p>
Solve it how you like. I don't particularly mind what sage does. I've given you the reasons why <span class="underline">I</span> won't be doing it. I think you can settle on some fixed example expression inside the error message, a la "A declaration along the lines of assume(x>0) may help solve your problem.", because the surgery that is currently done doesn't always lead to useful suggestions anyway, i.e.,
</p>
<pre class="wiki">sage: var('x,y')
sage: integrate(log(x^2+y^2),x,0,1)
</pre><p>
suggests <code>assume( (y+1)*(y-1) > 0 )</code> which doesn't make the question go away, and the fact that sage clearly goes out of its way to make a suggestion that doesn't turn out to help really does look silly.
Let's keep this issue outside the ticket comments, because they are getting too long to scroll already.
</p>
TicketkcrismanThu, 03 Mar 2011 01:45:14 GMT
https://trac.sagemath.org/ticket/7377#comment:102
https://trac.sagemath.org/ticket/7377#comment:102
<p>
There are tickets with three times as many comments, and I have never heard that complaint before. If a ticket causes a regression - and this is one, if slight - then that should be dealt with appropriately on that ticket.
</p>
<p>
If one insists that it is not relevant, or that it should not hold up a valuable improvement, then it would seem courteous for the person who believes it no longer belongs on that ticket to open a followup ticket along with relevant links to the discussion on the previous ticket. Given the work that has gone into this, that might be appropriate, but it seems to me it could also be dealt with on this one.
</p>
<p>
As to the error report, it doesn't always make it go away, sure. This is because some integration problems are just hard, and because Maxima can't do all the ones that might not be hard, and because Maxima's assumption framework is in fact weak, as they always say. It doesn't really seem any sillier than Maxima asking a million questions all to come up with the same answer.
</p>
TicketfbisseyThu, 03 Mar 2011 09:14:56 GMT
https://trac.sagemath.org/ticket/7377#comment:103
https://trac.sagemath.org/ticket/7377#comment:103
<p>
Tried all the patches on top of the current 4.7.alpha2. Apart from the already much discussed doctests errors mentioned so far I had one in interfaces/maxima_abstract.py
</p>
<pre class="wiki">sage -t -long -force_lib "devel/sage/sage/interfaces/maxima_abstract.py"
**********************************************************************
File "/usr/share/sage/devel/sage/sage/interfaces/maxima_abstract.py", line 197:
sage: sorted(maxima._commands(verbose=False))
Expected:
['Alpha',
'Beta',
...
'zunderflow']
Got:
['Alpha', 'Beta',
<cut a very long list>
'zunderflow', 'zz']
</pre>
TicketjpfloriThu, 03 Mar 2011 09:52:22 GMTattachment set
https://trac.sagemath.org/ticket/7377
https://trac.sagemath.org/ticket/7377
<ul>
<li><strong>attachment</strong>
set to <em>trac_7377-split_and_refactor-p2.patch</em>
</li>
</ul>
<p>
Updatred version for newlines in error reporting.
</p>
TicketjpfloriThu, 03 Mar 2011 09:57:55 GMT
https://trac.sagemath.org/ticket/7377#comment:104
https://trac.sagemath.org/ticket/7377#comment:104
<p>
I just updated the split_and_refactor patch to rmove supefluous calls to "terpri" and "mterpri".
</p>
<p>
I left the "strim-string" because it seems that "displa" adds one.
</p>
<p>
Anyway, there should be work done on error reporting (I'd say later, let's try to get the lib interface reviewed and merged now).
</p>
<p>
Nils and I got the same problem as François in maxima_abstract.
</p>
<p>
It's related to the data saved in ~/.sage/maxima_commandlist_cache.sobj which seems to get updated with unrelated data.
</p>
<p>
If you delete the file and rerun the test, it gives you what it should.
</p>
<p>
I'll have a look at it.
</p>
TicketjpfloriThu, 03 Mar 2011 09:59:19 GMTattachment set
https://trac.sagemath.org/ticket/7377
https://trac.sagemath.org/ticket/7377
<ul>
<li><strong>attachment</strong>
set to <em>trac_7377-unicode_to_ecl-p1.patch</em>
</li>
</ul>
<p>
Simpler patch not to slow exception propagation.
</p>
TicketjpfloriThu, 03 Mar 2011 10:00:15 GMTdescription changed
https://trac.sagemath.org/ticket/7377#comment:105
https://trac.sagemath.org/ticket/7377#comment:105
<ul>
<li><strong>description</strong>
modified (<a href="/ticket/7377?action=diff&version=105">diff</a>)
</li>
</ul>
TicketjpfloriThu, 03 Mar 2011 14:46:10 GMT
https://trac.sagemath.org/ticket/7377#comment:106
https://trac.sagemath.org/ticket/7377#comment:106
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/7377#comment:103" title="Comment 103">fbissey</a>:
</p>
<blockquote class="citation">
<p>
Tried all the patches on top of the current 4.7.alpha2. Apart from the already much discussed doctests errors mentioned so far I had one in interfaces/maxima_abstract.py <code> sage -t -long -force_lib "devel/sage/sage/interfaces/maxima_abstract.py" ********************************************************************** File "/usr/share/sage/devel/sage/sage/interfaces/maxima_abstract.py", line 197: sage: sorted(maxima._commands(verbose=False)) Expected: ['Alpha', 'Beta', ... 'zunderflow'] Got: ['Alpha', 'Beta', <cut a very long list> 'zunderflow', 'zz'] </code>
</p>
</blockquote>
<p>
The problem here is that some doctest in maxima_abstract.py creates something called 'zz' and if the test line 197 gets executed afterwards, self.__commands gets built then and includes 'zz', it fails... not really sure why this happens now and did not before.
</p>
<p>
If I put a call to self._commands() at the beginning of the doctest for trait_names(), self.__commands is built without 'zz'.
</p>
<p>
So we could consider that this is not a bug.
</p>
<p>
What's more problematic is that the result of _commands() gets cached and includes a fraction of random variable names (as 'sage???' and the problematic 'zz'). that was already the case before but fortunately no var between 'Alpha' and 'Beta' or after 'zunderflow' was created.
</p>
TicketkcrismanWed, 09 Mar 2011 21:35:17 GMT
https://trac.sagemath.org/ticket/7377#comment:107
https://trac.sagemath.org/ticket/7377#comment:107
<p>
Okay, I think I learned enough just barely enough Lisp now that I might be able to help on the assumptions/declarations issue.
</p>
<p>
However, there are other Maxima errors that might get reported. So one would, at the minimum, want to have a conditional error situation. One princ option wouldn't be enough. That seems to be a nightmare to do (at least for someone not an expert in Lisp). I even briefly wondered whether we might want Sage people at the command line to be able to interact and type 'y' like in Maxima, which perhaps is possible now... anyway, that was lies madness, at least for me.
</p>
<p>
So would it be terribly horrible to catch in the same way the function already does?
</p>
<pre class="wiki"> def sr_integral(self,*args):
try:
return max_to_sr(maxima_eval(([max_integrate],[sr_to_max(SR(a)) for a in args])))
except RuntimeError, error:
s = str(error)
if "Divergent" in s or "divergent" in s:
raise ValueError, "Integral is divergent."
else:
raise error
</pre><p>
This is only going to slow things down if there is, in fact, an error. I don't see why one couldn't put something here, if we are already going to catch divergent integrals. And this is basically how it was handled before.
</p>
<p>
One could similarly do this with <code>sr_limit</code> (what is <code>sr_tlimit</code>?), with examples like
</p>
<pre class="wiki">sage: var('a')
a
sage: limit(x^a,x=0)
<snip>
RuntimeError: ECL says: Maxima asks: Is a positive, negative, or zero?
</pre><p>
which, remarkably, is not in the doctests (there is no limit question-asking error, that is, despite the fact that Maxima certainly will ask about this).
</p>
<p>
Similarly, with the inconsistent assumptions, one could change the try/except
</p>
<pre class="wiki"> File "/Users/student/Desktop/sage-4.6.2/local/lib/python/site-packages/sage/symbolic/assumptions.py", line 104, in assume
maxima.eval("declare(%s, %s)" % (repr(self._var), self._assumption))
File "/Users/student/Desktop/sage-4.6.2/local/lib/python/site-packages/sage/interfaces/maxima_lib.py", line 266, in eval
if statement: result = ((result + '\n') if result else '') + max_to_string(maxima_eval("#$%s$"%statement))
File "ecl.pyx", line 619, in sage.libs.ecl.EclObject.__call__ (sage/libs/ecl.c:4425)
File "ecl.pyx", line 202, in sage.libs.ecl.ecl_safe_apply (sage/libs/ecl.c:2609)
RuntimeError: ECL says: Error executing code in Maxima: declare: inconsistent declaration declare(x,odd)
</pre><p>
in assumptions.py to look for a <a class="missing wiki">RuntimeError?</a>.
</p>
<p>
The latter is pretty easy to fix, I think. But hopefully all of these could lead to finishing this off.
<br />
</p>
<hr />
<p>
What about doctests? I noticed that definitely not all functions are doctested - no surprise, this is a huge project. Will that hold up merging of this, though?
</p>
<pre class="wiki">devel/sage/sage/interfaces//maxima_lib.py
SCORE devel/sage/sage/interfaces//maxima_lib.py: 37% (13 of 35)
devel/sage/sage/interfaces//maxima_abstract.py
SCORE devel/sage/sage/interfaces//maxima_abstract.py: 96% (78 of 81)
devel/sage/sage/interfaces//maxima.py
SCORE devel/sage/sage/interfaces//maxima.py: 61% (19 of 31)
</pre><p>
The current Maxima interface has 94 of 100 functions doctested. Just throwing it out there, I know jpflori also has mentioned it above, but this is a little data on it.
</p>
TicketjpfloriThu, 10 Mar 2011 15:27:30 GMT
https://trac.sagemath.org/ticket/7377#comment:108
https://trac.sagemath.org/ticket/7377#comment:108
<p>
So there are 3 identified problems left:
</p>
<ul><li>We could catch errors as suggested in the previous comment to report them as before. It could be changed back to something else in a later ticket (hopefully this ticket could be merged quickly, and anyway there is still a lot of work left to communicate directly with Maxima as a lib avoiding strings transformations).
</li><li>I'll try to add doctests this weekend.
</li><li>As far as the problem mentionned in comment 106 is concerned, we could mark its output as random or something like ![... ,gcd,...another function,...] (and modify commands() later if really needed).
</li></ul><p>
Afterwards the ticket would finally be ready for review.
</p>
TicketkcrismanThu, 10 Mar 2011 16:08:31 GMTdescription changed; work_issues set
https://trac.sagemath.org/ticket/7377#comment:109
https://trac.sagemath.org/ticket/7377#comment:109
<ul>
<li><strong>work_issues</strong>
set to <em>Maxima question doctests, 100% coverage, Maxima command list doctest</em>
</li>
<li><strong>description</strong>
modified (<a href="/ticket/7377?action=diff&version=109">diff</a>)
</li>
</ul>
<blockquote class="citation">
<ul><li>We could catch errors as suggested in the previous comment to report them as before. It could be changed back to something else in a later ticket (hopefully this ticket could be merged quickly, and anyway there is still a lot of work left to communicate directly with Maxima as a lib avoiding strings transformations).
</li></ul></blockquote>
<p>
Okay, that seems best to me as well so it can actually get merged. Presumably lots of potential followup tickets.
</p>
<p>
So I will try to do this today on top of the current list of patches, though I expect whatever I create will be merged by one of you into a p3 patch if that makes it easier to follow.
</p>
<blockquote class="citation">
<ul><li>I'll try to add doctests this weekend.
</li></ul></blockquote>
<p>
Impressive! Hopefully at least some can be nearly copied from the previous doctests (?)
</p>
<blockquote class="citation">
<ul><li>As far as the problem mentionned in comment 106 is concerned, we could mark its output as random or something like ![... ,gcd,...another function,...] (and modify commands() later if really needed).
</li></ul></blockquote>
<p>
Probably better to have an actual doctest like that, as random might allow weird things to slip through.
</p>
<blockquote class="citation">
<p>
Afterwards the ticket would finally be ready for review.
</p>
</blockquote>
<p>
Yes!
</p>
TicketkcrismanThu, 10 Mar 2011 17:17:50 GMT
https://trac.sagemath.org/ticket/7377#comment:110
https://trac.sagemath.org/ticket/7377#comment:110
<p>
Another minor issue with the doctests. Am I correct that <code>maxima</code> still gives the pexpect interface, while all 'calculus' stuff is done with the library interface? In that case the stuff about calculus at the top of <code>maxima.py</code> needs to be deleted, probably - perhaps put at the top of <code>maxima_lib.py</code>, since we would want to keep the doctests and information?
</p>
<p>
Also, probably JP, Nils, and/or Robert's names should be added at the top of these files!
</p>
TicketjpfloriThu, 10 Mar 2011 17:21:16 GMT
https://trac.sagemath.org/ticket/7377#comment:111
https://trac.sagemath.org/ticket/7377#comment:111
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/7377#comment:110" title="Comment 110">kcrisman</a>:
</p>
<blockquote class="citation">
<p>
Another minor issue with the doctests. Am I correct that <code>maxima</code> still gives the pexpect interface, while all 'calculus' stuff is done with the library interface? In that case the stuff about calculus at the top of <code>maxima.py</code> needs to be deleted, probably - perhaps put at the top of <code>maxima_lib.py</code>, since we would want to keep the doctests and information?
</p>
</blockquote>
<p>
You're right about maxima and calculus, I'll have a look at that while working on doctests.
</p>
<blockquote class="citation">
<p>
Also, probably JP, Nils, and/or Robert's names should be added at the top of these files!
</p>
</blockquote>
<p>
I'll do it also.
</p>
TicketkcrismanThu, 10 Mar 2011 17:36:59 GMT
https://trac.sagemath.org/ticket/7377#comment:112
https://trac.sagemath.org/ticket/7377#comment:112
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/7377#comment:111" title="Comment 111">jpflori</a>:
</p>
<blockquote class="citation">
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/7377#comment:110" title="Comment 110">kcrisman</a>:
</p>
<blockquote class="citation">
<p>
Another minor issue with the doctests. Am I correct that <code>maxima</code> still gives the pexpect interface, while all 'calculus' stuff is done with the library interface? In that case the stuff about calculus at the top of <code>maxima.py</code> needs to be deleted, probably - perhaps put at the top of <code>maxima_lib.py</code>, since we would want to keep the doctests and information?
</p>
</blockquote>
<p>
You're right about maxima and calculus, I'll have a look at that while working on doctests.
</p>
</blockquote>
<p>
Never mind, this is all correct as it stands. I have been singularly unhelpful, though not by design. Maybe one could copy the material at the top of <code>maxima.py</code> and put it in <code>maxima_lib.py</code> with a <code>from sage.interface.maxima_lib import maxima</code> at the very beginning, with some clarifying words. That would provide a double check, too.
</p>
<p>
There are also a few places in a few docs that still mention expect wrongly, I think - I'll keep looking for them.
</p>
<p>
Issues I think I can deal with while taking care of the error handling:
</p>
<ul><li><code>maxima._expect_expr</code>, while usefully staying the same as before, certainly isn't doctested by those tests any more.
</li><li>Can the old <code>sr_integral</code> etc. in <code>maxima.py</code> be removed, or should they be kept in case someone wanted to use the pexpect for doing calculus? I would think remove.
</li><li>With respect to <code>sr_sum</code> and <code>sr_integral</code>, since they are implementing the divergent integral/sum check, should we remove those from <code>calculus.py</code> and <code>symbolic.integration.external.py</code>? Those pieces of code will probably never be reached, since the ValueError is already raised in <code>maxima_lib.py</code>.
</li></ul><p>
I'll keep looking for things like this, hopefully catch as many as possible.
</p>
TicketkcrismanThu, 10 Mar 2011 21:25:09 GMT
https://trac.sagemath.org/ticket/7377#comment:113
https://trac.sagemath.org/ticket/7377#comment:113
<p>
Okay, while this patch is not 100% ready, it is certainly good enough to look at and give feedback on. It takes care of the three things I mention above, and adds a little doctesting. It also documents <code>assume</code> more comprehensively early in its docstring.
</p>
<p>
I get a weird error with this, though:
</p>
<pre class="wiki">sage: sage: var('x, n')
(x, n)
sage: sage: integral(x^n,x)
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', (534, 0))
<snip - then the expected ValueError>
</pre><p>
which I cannot explain.
</p>
TicketkcrismanThu, 10 Mar 2011 21:26:20 GMTattachment set
https://trac.sagemath.org/ticket/7377
https://trac.sagemath.org/ticket/7377
<ul>
<li><strong>attachment</strong>
set to <em>trac_7377-assumptions.patch</em>
</li>
</ul>
<p>
Trial patch to improve assumption messages and documentation of helper functions
</p>
TicketjpfloriMon, 14 Mar 2011 15:58:17 GMTattachment set
https://trac.sagemath.org/ticket/7377
https://trac.sagemath.org/ticket/7377
<ul>
<li><strong>attachment</strong>
set to <em>trac_7377-assumptions-p1.patch</em>
</li>
</ul>
<p>
Slightly reworked patch.
</p>
TicketjpfloriMon, 14 Mar 2011 15:59:06 GMTattachment set
https://trac.sagemath.org/ticket/7377
https://trac.sagemath.org/ticket/7377
<ul>
<li><strong>attachment</strong>
set to <em>trac_7377-doctests.patch</em>
</li>
</ul>
<p>
(Really) basic tests and doc for every functions in sage.interfaces.maxima*
</p>
TicketjpfloriMon, 14 Mar 2011 16:07:54 GMTdescription changed; work_issues deleted
https://trac.sagemath.org/ticket/7377#comment:114
https://trac.sagemath.org/ticket/7377#comment:114
<ul>
<li><strong>description</strong>
modified (<a href="/ticket/7377?action=diff&version=114">diff</a>)
</li>
<li><strong>work_issues</strong>
<em>Maxima question doctests, 100% coverage, Maxima command list doctest</em> deleted
</li>
</ul>
<p>
We now have 100% ((really) basic (and stupid)) doctests coverage.
</p>
<p>
I also fixed some minor issues here and there.
</p>
<p>
What could be postponed to later tickets:
</p>
<ul><li>better doctests
</li><li>better error handling
</li><li>better conversions between maxima and sr
</li><li>reorganize the code in maxima_lib to make it clearer
</li></ul>
TicketkcrismanMon, 14 Mar 2011 16:37:58 GMT
https://trac.sagemath.org/ticket/7377#comment:115
https://trac.sagemath.org/ticket/7377#comment:115
<p>
Thanks for catching the calculus/functional one. I also noticed something that will cause a Sphinx error - which was my bad - so I'm uploading a trivially changed p2.
</p>
TicketkcrismanMon, 14 Mar 2011 16:40:41 GMTattachment set
https://trac.sagemath.org/ticket/7377
https://trac.sagemath.org/ticket/7377
<ul>
<li><strong>attachment</strong>
set to <em>trac_7377-assumptions-p2.patch</em>
</li>
</ul>
<p>
trivial correction to p1 patch
</p>
TicketkcrismanMon, 14 Mar 2011 17:00:08 GMTstatus, description changed
https://trac.sagemath.org/ticket/7377#comment:116
https://trac.sagemath.org/ticket/7377#comment:116
<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/7377?action=diff&version=116">diff</a>)
</li>
</ul>
<p>
Sorry I do not have time to check this properly today. Do you get the
</p>
<pre class="wiki">ERROR: An unexpected error occurred while tokenizing input
The following traceback may be corrupted or invalid
</pre><p>
problem with these patches? I hope not :)
</p>
<p>
A couple very small points about the doctests patch, which by the way is nontrivial and nice all by itself.
</p>
<ul><li>You should have a <code>loads(dumps(foo))==foo</code> test if possible for class definitions. I think there are eight of these?
</li><li>You probably don't need to put <code>INPUT</code> and/or <code>OUTPUT</code> blocks if there isn't one or it's essentially stated in the first line of the documentation - I'm thinking of <code>_false_symbol</code> or <code>version</code>. Up to you, of course, since you already did it.
</li><li>In a few places where you have more than 'really basic and stupid' documentation (you sell yourself short! it's not bad at all) you have some lines that aren't going to work. Ones like
<pre class="wiki">- ``use_disk_cache`` - boolean (default: True); if set to True, try to read cached result from disk
</pre></li></ul><p>
are too long, and should be made into two lines like you did for
</p>
<pre class="wiki">- ``eqns`` - a list of m strings; each representing a linear
question in m = n variables
</pre><p>
However, these will cause a problem in Sphinx, I think, unless you reformat them like so
</p>
<pre class="wiki">- ``eqns`` - a list of m strings; each representing a linear
question in m = n variables
</pre><p>
This won't show up well on Trac, but notice that the 'q' in 'question' is lined up with the first '<code>' in '</code><code>eqns</code>`'. This was correctly done for 'pts_list', for example.
</p>
<p>
It looks like the <code>zunderflow zz</code> was fixed as well, and assuming that fix passes tests as well, I think it can be 'needs review'.
</p>
<p>
In fact, as long as everyone involved is not reviewing their own patch, this can even be 'positive review'. For instance, I will assume that JP slightly changing my reviewer patch indicates no problems with it.
</p>
<p>
Can anyone say what would still need to be done for positive review, other than passing all long doctests, which I can't check right now, and taking care of the things above which will lead to Sphinx errors?
</p>
TicketkcrismanMon, 14 Mar 2011 17:03:59 GMT
https://trac.sagemath.org/ticket/7377#comment:117
https://trac.sagemath.org/ticket/7377#comment:117
<blockquote class="citation">
<p>
Can anyone say what would still need to be done for positive review, other than passing all long doctests, which I can't check right now, and taking care of the things above which will lead to Sphinx errors?
</p>
</blockquote>
<p>
Sorry, and adding the loads/dumps tests, if they are possible. Some should be, based on the discussion about pickling above and previous behavior working:
</p>
<pre class="wiki">----------------------------------------------------------------------
| Sage Version 4.6.2, Release Date: 2011-02-25 |
| Type notebook() for the GUI, and license() for information. |
----------------------------------------------------------------------
sage: loads(dumps(Maxima))==Maxima
True
sage: a = maxima(5)
sage: type(a)
<class 'sage.interfaces.maxima.MaximaElement'>
sage: loads(dumps(a))==a
True
</pre>
TicketjpfloriMon, 14 Mar 2011 17:14:48 GMT
https://trac.sagemath.org/ticket/7377#comment:118
https://trac.sagemath.org/ticket/7377#comment:118
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/7377#comment:116" title="Comment 116">kcrisman</a>:
</p>
<blockquote class="citation">
<p>
Sorry I do not have time to check this properly today. Do you get the <code> ERROR: An unexpected error occurred while tokenizing input The following traceback may be corrupted or invalid </code> problem with these patches? I hope not :)
</p>
</blockquote>
<p>
I do not get that one.
</p>
<blockquote class="citation">
<p>
A couple very small points about the doctests patch, which by the way is nontrivial and nice all by itself. * You should have a <code>loads(dumps(foo))==foo</code> test if possible for class definitions. I think there are eight of these? * You probably don't need to put <code>INPUT</code> and/or <code>OUTPUT</code> blocks if there isn't one or it's essentially stated in the first line of the documentation - I'm thinking of <code>_false_symbol</code> or <code>version</code>. Up to you, of course, since you already did it. * In a few places where you have more than 'really basic and stupid' documentation (you sell yourself short! it's not bad at all) you have some lines that aren't going to work. Ones like <code> - use_disk_cache - boolean (default: True); if set to True, try to read cached result from disk </code> are too long, and should be made into two lines like you did for <code> - eqns - a list of m strings; each representing a linear question in m = n variables </code> However, these will cause a problem in Sphinx, I think, unless you reformat them like so <code> - eqns - a list of m strings; each representing a linear question in m = n variables </code> This won't show up well on Trac, but notice that the 'q' in 'question' is lined up with the first '<code>' in '</code><code>eqns</code>`'. This was correctly done for 'pts_list', for example.
</p>
</blockquote>
<p>
I was not aware of line length limitation, I'll have a look at that tonight. For the eqns one, you are right, I just forgot to indent it correctly.
</p>
<p>
For the INPUT and OUTPUT blocks, I just tried to follow <a href="http://www.sagemath.org/doc/developer/conventions.html">http://www.sagemath.org/doc/developer/conventions.html</a> as much as possible to get something consistent even if it is often redundant or empty.
</p>
<blockquote class="citation">
<p>
It looks like the <code>zunderflow zz</code> was fixed as well, and assuming that fix passes tests as well, I think it can be 'needs review'. In fact, as long as everyone involved is not reviewing their own patch, this can even be 'positive review'. For instance, I will assume that JP slightly changing my reviewer patch indicates no problems with it. Can anyone say what would still need to be done for positive review, other than passing all long doctests, which I can't check right now, and taking care of the things above which will lead to Sphinx errors?
</p>
</blockquote>
<p>
It is fixed because I changed the check to something else.
</p>
<p>
The real problem is that this test gives a somewhat random output according to when it is run.
</p>
<p>
So I guess the problem, if there is one, does not lie in the test used now, but in the implementation of the function itself.
</p>
<p>
See <a class="ext-link" href="http://trac.sagemath.org/sage_trac/ticket/7377#comment:106"><span class="icon"></span>http://trac.sagemath.org/sage_trac/ticket/7377#comment:106</a> I guess we could open another ticket if we want to change the current behavior.
</p>
TicketkcrismanMon, 14 Mar 2011 17:25:11 GMTstatus, reviewer changed; work_issues set
https://trac.sagemath.org/ticket/7377#comment:119
https://trac.sagemath.org/ticket/7377#comment:119
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>needs_work</em>
</li>
<li><strong>reviewer</strong>
changed from <em>Jean-Pierre Flori, François Bissey, Karl-Dieter Crisman</em> to <em>Jean-Pierre Flori, François Bissey, Karl-Dieter Crisman, Nils Bruin</em>
</li>
<li><strong>work_issues</strong>
set to <em>loads(dumps()), very minor doctest formatting issues</em>
</li>
</ul>
<blockquote class="citation">
<p>
I was not aware of line length limitation, I'll have a look at that tonight. For the eqns one, you are right, I just forgot to indent it correctly.
</p>
</blockquote>
<p>
It's not hard and fast, but it makes it so that when it shows up in a terminal window it doesn't look weird.
</p>
<blockquote class="citation">
<p>
For the INPUT and OUTPUT blocks, I just tried to follow <a href="http://www.sagemath.org/doc/developer/conventions.html">http://www.sagemath.org/doc/developer/conventions.html</a> as much as possible to get something consistent even if it is often redundant or empty.
</p>
</blockquote>
<p>
Maybe we need to add something here about that...
</p>
<blockquote class="citation">
<p>
It is fixed because I changed the check to something else.
</p>
</blockquote>
<p>
Yes, I saw that the fix was the one you suggested earlier - sorry for not being clear about that.
</p>
<blockquote class="citation">
<p>
The real problem is that this test gives a somewhat random output according to when it is run.
</p>
</blockquote>
<p>
Well, not too bad. One would expect this, given the nature of the function.
</p>
<p>
Okay, so I'll put this to 'needs work' and then hopefully it will be very easy to produce a p1 of the doctests patch that has the loads/dumps and fixes the other very minor issues. I can try to review that patch tomorrow or Wednesday (US East Coast) and run tests.
</p>
<p>
Can you think of anything that you have done that hasn't been positively reviewed by Nils or Francois? It's a little hard to determine that from the comments. At any rate this will be one of the better-tested major changes in how we interface to a sub-program, thanks to the long gestation period.
</p>
TicketkcrismanMon, 14 Mar 2011 17:26:28 GMT
https://trac.sagemath.org/ticket/7377#comment:120
https://trac.sagemath.org/ticket/7377#comment:120
<blockquote class="citation">
<p>
Okay, so I'll put this to 'needs work' and then hopefully it will be very easy to produce a p1 of the doctests patch
</p>
</blockquote>
<p>
For you, I mean :) I don't have access to the computer where I tested all this right now, and unfortunately not time to do it on this one today.
</p>
TicketfbisseyTue, 15 Mar 2011 01:57:49 GMT
https://trac.sagemath.org/ticket/7377#comment:121
https://trac.sagemath.org/ticket/7377#comment:121
<p>
After applying the patches I am now getting:
</p>
<pre class="wiki">sage -t -force_lib "devel/sage-main/sage/symbolic/assumptions.py"
**********************************************************************
File "/usr/share/sage/devel/sage-main/sage/symbolic/assumptions.py", line 89:
sage: decl2.assume()
Expected:
Traceback (most recent call last):
...
ValueError: Assumption is inconsistent
Got:
Traceback (most recent call last):
File "/usr/bin/ncadoctest.py", line 1231, in run_one_test
self.run_one_example(test, example, filename, compileflags)
File "/usr/bin/sagedoctest.py", line 38, in run_one_example
OrigDocTestRunner.run_one_example(self, test, example, filename, compileflags)
File "/usr/bin/ncadoctest.py", line 1172, in run_one_example
compileflags, 1) in test.globs
File "<doctest __main__.example_3[7]>", line 1, in <module>
decl2.assume()###line 89:
sage: decl2.assume()
File "/usr/lib64/python2.6/site-packages/sage/symbolic/assumptions.py", line 104, in assume
maxima.eval("declare(%s, %s)" % (repr(self._var), self._assumption))
File "/usr/lib64/python2.6/site-packages/sage/interfaces/maxima_lib.py", line 395, in _eval_line
if statement: result = ((result + '\n') if result else '') + max_to_string(maxima_eval("#$%s$"%statement))
File "ecl.pyx", line 619, in sage.libs.ecl.EclObject.__call__ (sage/libs/ecl.c:4422)
File "ecl.pyx", line 202, in sage.libs.ecl.ecl_safe_apply (sage/libs/ecl.c:2606)
RuntimeError: ECL says: Error executing code in Maxima: declare: inconsistent declaration declare(x,odd)
**********************************************************************
File "/usr/share/sage/devel/sage-main/sage/symbolic/assumptions.py", line 294:
sage: sum(a*q^k, k, 0, oo)
Expected:
Traceback (most recent call last):
...
ValueError: Sum is divergent.
Got:
Traceback (most recent call last):
File "/usr/bin/ncadoctest.py", line 1231, in run_one_test
self.run_one_example(test, example, filename, compileflags)
File "/usr/bin/sagedoctest.py", line 38, in run_one_example
OrigDocTestRunner.run_one_example(self, test, example, filename, compileflags)
File "/usr/bin/ncadoctest.py", line 1172, in run_one_example
compileflags, 1) in test.globs
File "<doctest __main__.example_7[12]>", line 1, in <module>
sum(a*q**k, k, Integer(0), oo)###line 294:
sage: sum(a*q^k, k, 0, oo)
NameError: name 'k' is not defined
**********************************************************************
File "/usr/share/sage/devel/sage-main/sage/symbolic/assumptions.py", line 300:
sage: sum(a*q^k, k, 0, oo)
Exception raised:
Traceback (most recent call last):
File "/usr/bin/ncadoctest.py", line 1231, in run_one_test
self.run_one_example(test, example, filename, compileflags)
File "/usr/bin/sagedoctest.py", line 38, in run_one_example
OrigDocTestRunner.run_one_example(self, test, example, filename, compileflags)
File "/usr/bin/ncadoctest.py", line 1172, in run_one_example
compileflags, 1) in test.globs
File "<doctest __main__.example_7[15]>", line 1, in <module>
sum(a*q**k, k, Integer(0), oo)###line 300:
sage: sum(a*q^k, k, 0, oo)
NameError: name 'k' is not defined
**********************************************************************
File "/usr/share/sage/devel/sage-main/sage/symbolic/assumptions.py", line 340:
sage: assume(x,'odd')
Expected:
Traceback (most recent call last):
...
ValueError: Assumption is inconsistent
Got:
Traceback (most recent call last):
File "/usr/bin/ncadoctest.py", line 1231, in run_one_test
self.run_one_example(test, example, filename, compileflags)
File "/usr/bin/sagedoctest.py", line 38, in run_one_example
OrigDocTestRunner.run_one_example(self, test, example, filename, compileflags)
File "/usr/bin/ncadoctest.py", line 1172, in run_one_example
compileflags, 1) in test.globs
File "<doctest __main__.example_7[32]>", line 1, in <module>
assume(x,'odd')###line 340:
sage: assume(x,'odd')
File "/usr/lib64/python2.6/site-packages/sage/symbolic/assumptions.py", line 390, in assume
x.assume()
File "/usr/lib64/python2.6/site-packages/sage/symbolic/assumptions.py", line 104, in assume
maxima.eval("declare(%s, %s)" % (repr(self._var), self._assumption))
File "/usr/lib64/python2.6/site-packages/sage/interfaces/maxima_lib.py", line 395, in _eval_line
if statement: result = ((result + '\n') if result else '') + max_to_string(maxima_eval("#$%s$"%statement))
File "ecl.pyx", line 619, in sage.libs.ecl.EclObject.__call__ (sage/libs/ecl.c:4422)
File "ecl.pyx", line 202, in sage.libs.ecl.ecl_safe_apply (sage/libs/ecl.c:2606)
RuntimeError: ECL says: Error executing code in Maxima: declare: inconsistent declaration declare(x,odd)
**********************************************************************
</pre><p>
and
</p>
<pre class="wiki">sage -t -force_lib "devel/sage-main/sage/symbolic/integration/integral.py"
**********************************************************************
File "/usr/share/sage/devel/sage-main/sage/symbolic/integration/integral.py", line 356:
sage: integrate(1/x^3,x,-1,3)
Expected:
Traceback (most recent call last):
...
ValueError: Integral is divergent.
Got:
4/9
**********************************************************************
File "/usr/share/sage/devel/sage-main/sage/symbolic/integration/integral.py", line 446:
sage: integrate(1/(x^3 *(a+b*x)^(1/3)), x)
Expected:
Traceback (most recent call last):
...
TypeError: Computation failed since Maxima requested additional constraints (try the command 'assume(a>0)' before integral or limit evaluation, for example):
Is a positive or negative?
Got:
Traceback (most recent call last):
File "/usr/bin/ncadoctest.py", line 1231, in run_one_test
self.run_one_example(test, example, filename, compileflags)
File "/usr/bin/sagedoctest.py", line 38, in run_one_example
OrigDocTestRunner.run_one_example(self, test, example, filename, compileflags)
File "/usr/bin/ncadoctest.py", line 1172, in run_one_example
compileflags, 1) in test.globs
File "<doctest __main__.example_10[47]>", line 1, in <module>
integrate(Integer(1)/(x**Integer(3) *(a+b*x)**(Integer(1)/Integer(3))), x)###line 446:
sage: integrate(1/(x^3 *(a+b*x)^(1/3)), x)
File "/usr/lib64/python2.6/site-packages/sage/misc/functional.py", line 718, in integral
return x.integral(*args, **kwds)
File "expression.pyx", line 8188, in sage.symbolic.expression.Expression.integral (sage/symbolic/expression.cpp:31363)
File "/usr/lib64/python2.6/site-packages/sage/symbolic/integration/integral.py", line 601, in integrate
return indefinite_integral(expression, v)
File "function.pyx", line 419, in sage.symbolic.function.Function.__call__ (sage/symbolic/function.cpp:4504)
File "/usr/lib64/python2.6/site-packages/sage/symbolic/integration/integral.py", line 85, in _eval_
res = integrator(f, x)
File "/usr/lib64/python2.6/site-packages/sage/symbolic/integration/external.py", line 19, in maxima_integrator
result = maxima.sr_integral(expression,v)
File "/usr/lib64/python2.6/site-packages/sage/interfaces/maxima_lib.py", line 654, in sr_integral
raise ValueError, "Computation failed since Maxima requested additional constraints; using the 'assume' command before integral evaluation *may* help (example of legal syntax is 'assume(" + s[4:k] +">0)', see `assume?` for more details)\n" + s
ValueError: Computation failed since Maxima requested additional constraints; using the 'assume' command before integral evaluation *may* help (example of legal syntax is 'assume(a>0)', see `assume?` for more details)
Is a positive or negative?
**********************************************************************
File "/usr/share/sage/devel/sage-main/sage/symbolic/integration/integral.py", line 484:
sage: res = integral(f,x,0.0001414, 1.); res
Expected:
Traceback (most recent call last):
...
TypeError: Computation failed since Maxima requested additional
constraints (try the command 'assume((y-1)*(y+1)>0)' before integral
or limit evaluation, for example):
Is (y-1)*(y+1) positive, negative, or zero?
Got:
Traceback (most recent call last):
File "/usr/bin/ncadoctest.py", line 1231, in run_one_test
self.run_one_example(test, example, filename, compileflags)
File "/usr/bin/sagedoctest.py", line 38, in run_one_example
OrigDocTestRunner.run_one_example(self, test, example, filename, compileflags)
File "/usr/bin/ncadoctest.py", line 1172, in run_one_example
compileflags, 1) in test.globs
File "<doctest __main__.example_10[56]>", line 1, in <module>
res = integral(f,x,RealNumber('0.0001414'), RealNumber('1.')); res###line 484:
sage: res = integral(f,x,0.0001414, 1.); res
File "/usr/lib64/python2.6/site-packages/sage/misc/functional.py", line 718, in integral
return x.integral(*args, **kwds)
File "expression.pyx", line 8188, in sage.symbolic.expression.Expression.integral (sage/symbolic/expression.cpp:31363)
File "/usr/lib64/python2.6/site-packages/sage/symbolic/integration/integral.py", line 603, in integrate
return definite_integral(expression, v, a, b)
File "function.pyx", line 414, in sage.symbolic.function.Function.__call__ (sage/symbolic/function.cpp:4443)
File "/usr/lib64/python2.6/site-packages/sage/symbolic/integration/integral.py", line 174, in _eval_
return integrator(*args)
File "/usr/lib64/python2.6/site-packages/sage/symbolic/integration/external.py", line 21, in maxima_integrator
result = maxima.sr_integral(expression, v, a, b)
File "/usr/lib64/python2.6/site-packages/sage/interfaces/maxima_lib.py", line 654, in sr_integral
raise ValueError, "Computation failed since Maxima requested additional constraints; using the 'assume' command before integral evaluation *may* help (example of legal syntax is 'assume(" + s[4:k] +">0)', see `assume?` for more details)\n" + s
ValueError: Computation failed since Maxima requested additional constraints; using the 'assume' command before integral evaluation *may* help (example of legal syntax is 'assume((y-1)*(y+1)>0)', see `assume?` for more details)
Is (y-1)*(y+1) positive, negative, or zero?
</pre><p>
Did I forget a patch or somehow something didn't apply?
</p>
TicketkcrismanTue, 15 Mar 2011 03:03:14 GMTwork_issues changed
https://trac.sagemath.org/ticket/7377#comment:122
https://trac.sagemath.org/ticket/7377#comment:122
<ul>
<li><strong>work_issues</strong>
changed from <em>loads(dumps()), very minor doctest formatting issues</em> to <em>loads(dumps()), very minor doctest formatting issues, a few remaining doctest errors</em>
</li>
</ul>
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/7377#comment:121" title="Comment 121">fbissey</a>:
</p>
<blockquote class="citation">
<p>
After applying the patches I am now getting:
</p>
</blockquote>
<p>
Thank you so much! I knew I was tired when I made that patch, hence it not being quite ready for prime time. To be fair, I warned of this. But it shouldn't be too bad to make a p3 of it.
</p>
<p>
{{[
</p>
<blockquote class="citation">
<p>
sage -t -force_lib "devel/sage-main/sage/symbolic/assumptions.py"
<strong></strong><strong></strong><strong></strong><strong></strong><strong></strong><strong></strong><strong></strong><strong></strong><strong></strong><strong></strong><strong></strong><strong></strong><strong></strong><strong></strong><strong></strong><strong></strong><strong></strong><strong>
File "/usr/share/sage/devel/sage-main/sage/symbolic/assumptions.py", line 89:
</strong></p>
<blockquote>
<p>
sage: decl2.assume()
</p>
</blockquote>
<p>
Expected:
</p>
<blockquote>
<p>
Traceback (most recent call last):
...
<a class="missing wiki">ValueError?</a>: Assumption is inconsistent
<a class="missing wiki">RuntimeError?</a>: ECL says: Error executing code in Maxima: declare: inconsistent declaration declare(x,odd)
</strong></p>
</blockquote>
<p>
<strong></strong><strong></strong><strong></strong><strong></strong><strong></strong><strong></strong><strong></strong><strong></strong><strong></strong><strong></strong><strong></strong><strong></strong><strong></strong><strong></strong><strong></strong><strong></strong><strong></strong><strong>
File "/usr/share/sage/devel/sage-main/sage/symbolic/assumptions.py", line 340:
</p>
<blockquote>
<p>
sage: assume(x,'odd')
</p>
</blockquote>
<p>
Expected:
</p>
<blockquote>
<p>
Traceback (most recent call last):
...
<a class="missing wiki">ValueError?</a>: Assumption is inconsistent
<a class="missing wiki">RuntimeError?</a>: ECL says: Error executing code in Maxima: declare: inconsistent declaration declare(x,odd)
</strong></p>
</blockquote>
<p>
<strong></strong><strong></strong><strong></strong><strong></strong><strong></strong><strong></strong><strong></strong><strong></strong><strong></strong><strong></strong><strong></strong><strong></strong><strong></strong><strong></strong><strong></strong><strong></strong><strong></strong><strong>
</p>
</blockquote>
<p>
}}}
In this case, the new message is just as informative as the old one (though longer). So we could just replace all of those and remove the catch for inconsistent declarations in the code, I guess.
</p>
<pre class="wiki">> **********************************************************************
> File "/usr/share/sage/devel/sage-main/sage/symbolic/assumptions.py", line 294:
> sage: sum(a*q^k, k, 0, oo)
> NameError: name 'k' is not defined
</pre><p>
Oops. Sorry. Same for the next one.
</p>
<pre class="wiki">> File "/usr/share/sage/devel/sage-main/sage/symbolic/assumptions.py", line 300:
> sage: sum(a*q^k, k, 0, oo)
> NameError: name 'k' is not defined
</pre><p>
This is interesting. That means we can't just remove the piece about this in the integration code, as I thought. Since ECL returns the divergent error, it seemed like we could, but apparently skipping the error still outputs the principal value. I would need someone with knowledge of how the new interface works to figure out how to make sure this reports an error.
</p>
<pre class="wiki">> sage -t -force_lib "devel/sage-main/sage/symbolic/integration/integral.py"
> **********************************************************************
> File "/usr/share/sage/devel/sage-main/sage/symbolic/integration/integral.py", line 356:
> sage: integrate(1/x^3,x,-1,3)
> Expected:
> Traceback (most recent call last):
> ...
> ValueError: Integral is divergent.
> Got:
> 4/9
</pre><p>
Same thing for this one - we are catching it, but it still prints the question. How do we make sure it doesn't do that? I don't think it did that before, so it may be one of the apparently-not-innocuous things JP removed in the last patch.
</p>
<pre class="wiki">> sage: integrate(1/(x^3 *(a+b*x)^(1/3)), x)
> ValueError: Computation failed since Maxima requested additional constraints; using the 'assume' command before integral evaluation *may* help (example of legal syntax is 'assume(a>0)', see `assume?` for more details)
> Is a positive or negative?
> **********************************************************************
> File "/usr/share/sage/devel/sage-main/sage/symbolic/integration/integral.py", line 484:
> sage: res = integral(f,x,0.0001414, 1.); res
> ValueError: Computation failed since Maxima requested additional constraints; using the 'assume' command before integral evaluation *may* help (example of legal syntax is 'assume((y-1)*(y+1)>0)', see `assume?` for more details)
> Is (y-1)*(y+1) positive, negative, or zero?
</pre>
TicketjpfloriTue, 15 Mar 2011 09:33:18 GMTattachment set
https://trac.sagemath.org/ticket/7377
https://trac.sagemath.org/ticket/7377
<ul>
<li><strong>attachment</strong>
set to <em>trac_7377-assumptions-p3.patch</em>
</li>
</ul>
<p>
More fixes
</p>
TicketjpfloriTue, 15 Mar 2011 13:01:25 GMTattachment set
https://trac.sagemath.org/ticket/7377
https://trac.sagemath.org/ticket/7377
<ul>
<li><strong>attachment</strong>
set to <em>trac_7377-doctests-p1.patch</em>
</li>
</ul>
<p>
Updated doctests.
</p>
TicketjpfloriTue, 15 Mar 2011 13:08:08 GMTdescription changed; work_issues deleted
https://trac.sagemath.org/ticket/7377#comment:123
https://trac.sagemath.org/ticket/7377#comment:123
<ul>
<li><strong>work_issues</strong>
<em>loads(dumps()), very minor doctest formatting issues, a few remaining doctest errors</em> deleted
</li>
<li><strong>description</strong>
modified (<a href="/ticket/7377?action=diff&version=123">diff</a>)
</li>
</ul>
<p>
I uploaded updated versions of both last patches. I accidently deleted two lines in the previous one which cause the principal error, they are restored now. I added pickling tests, not sure they make sense. Also some various fixes and cosmetic changes to reduce line lengths for sphynx and readibility.
</p>
<p>
Afterwards "make ptestlong" reported no errors on my computer.
</p>
<p>
Don't know if someone already took a look at what I did to split Interface class out of Expect class.
</p>
<p>
It seems functional now, but maybe I left some mistakes there.
</p>
TicketkcrismanTue, 15 Mar 2011 13:33:07 GMT
https://trac.sagemath.org/ticket/7377#comment:124
https://trac.sagemath.org/ticket/7377#comment:124
<p>
Thanks, JP - I was planning on making the fixes today, but you beat me to it. They were all oversights of mine, except...
</p>
<blockquote class="citation">
<p>
I uploaded updated versions of both last patches. I accidently deleted two lines in the previous one which cause the principal error, they are restored now.
</p>
</blockquote>
<p>
Ah, I wondered if that ecl principal value thing was important.
</p>
<blockquote class="citation">
<p>
I added pickling tests, not sure they make sense.
</p>
</blockquote>
<p>
I don't know if they do either, but this is one of the things Sage has come to a consensus on, for better or for worse. Some were already there, as it turned out - in the <code>__init__</code>, not class definition - but doesn't hurt to have the others.
</p>
<blockquote class="citation">
<p>
Also some various fixes and cosmetic changes to reduce line lengths for sphynx and readibility.
</p>
</blockquote>
<p>
I'll check that all out next, after running my own tests. There is one final 'evalutation' that I should be able to fix very easily.
</p>
<blockquote class="citation">
<p>
Afterwards "make ptestlong" reported no errors on my computer.
</p>
<p>
Don't know if someone already took a look at what I did to split Interface class out of Expect class.
</p>
</blockquote>
<p>
I'll try to look at it, but I fear there is a little too much ECL there for me to feel comfortable reviewing that.
</p>
<blockquote class="citation">
<p>
It seems functional now, but maybe I left some mistakes there.
</p>
</blockquote>
<p>
Maybe Francois can then give positive review :)
</p>
<p>
I should point out that if this depends on <a class="closed ticket" href="https://trac.sagemath.org/ticket/10743" title="enhancement: Add iterator protocol to EclObject (closed: fixed)">#10743</a>, in principle this ticket's positive review wouldn't be very useful until that one is reviewed.
</p>
TicketkcrismanTue, 15 Mar 2011 17:21:40 GMTattachment set
https://trac.sagemath.org/ticket/7377
https://trac.sagemath.org/ticket/7377
<ul>
<li><strong>attachment</strong>
set to <em>trac_7377-doctests-p2.patch</em>
</li>
</ul>
<p>
Updated to fix two trivial typos
</p>
TicketkcrismanTue, 15 Mar 2011 17:24:52 GMTstatus, description changed
https://trac.sagemath.org/ticket/7377#comment:125
https://trac.sagemath.org/ticket/7377#comment:125
<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/7377?action=diff&version=125">diff</a>)
</li>
</ul>
<p>
Coverage is great, I haven't tested formatting in built html but looks like it will be fine overall, and in general very impressive work here. The refactoring is at least working well with the interfaces in doctesting; it would be nice to have more testing of that by heavy users of (say) R or GAP, but at the very least we can set to 'needs review'.
</p>
TicketkcrismanTue, 15 Mar 2011 19:33:55 GMT
https://trac.sagemath.org/ticket/7377#comment:126
https://trac.sagemath.org/ticket/7377#comment:126
<p>
Okay, the HTML docs look fine in general. Good catch on a few of the indentations that were incorrect before in any case.
</p>
<pre class="wiki"> 1.
Sage can currently only understand a subset of the output of Maxima,
Maple and Mathematica, so even if the chosen backend can perform
the summation the result might not be convertable into a Sage
expression.
</pre><p>
shouldn't be double-spaced, but this is not really a big deal because it still looks ok.
</p>
<p>
More importantly, but still not enough to stop positive review, is the fact that the new files are not in the documentation! We will need to fix <code>interfaces.rst</code> in the sage/doc/en/ folder to be accurate, as well as to include the new <code>sage/interfaces/maxima_lib</code>, <code>sage/interfaces/maxima_abstract</code>, and <code>sage/interfaces/interface</code> documentation. This is now <a class="closed ticket" href="https://trac.sagemath.org/ticket/10942" title="enhancement: Update interfaces.rst for changes in the interfaces (closed: fixed)">#10942</a>.
</p>
TicketfbisseyTue, 15 Mar 2011 21:19:37 GMT
https://trac.sagemath.org/ticket/7377#comment:127
https://trac.sagemath.org/ticket/7377#comment:127
<p>
All done the long tests passed with flying colors. No more problems for me, I am happy with it.
</p>
TicketfbisseyWed, 16 Mar 2011 02:04:09 GMT
https://trac.sagemath.org/ticket/7377#comment:128
https://trac.sagemath.org/ticket/7377#comment:128
<p>
It's embarrassing I hadn't recompiled with the patches in. Re-running the long test now.
</p>
TicketfbisseyWed, 16 Mar 2011 22:03:37 GMT
https://trac.sagemath.org/ticket/7377#comment:129
https://trac.sagemath.org/ticket/7377#comment:129
<p>
I had made some extra comments yesterday but obviously it was during the time trac was having a fit. So I'll repeat. I have one failing test left
</p>
<pre class="wiki">sage -t -long -force_lib "devel/sage-main/sage/symbolic/integration/integral.py"
**********************************************************************
File "/usr/share/sage/devel/sage-main/sage/symbolic/integration/integral.py", line 359:
sage: integrate(1/x^3,x,-1,3)
Expected:
Traceback (most recent call last):
...
ValueError: Integral is divergent.
Got:
4/9
**********************************************************************
</pre>
TicketkcrismanWed, 16 Mar 2011 23:16:00 GMT
https://trac.sagemath.org/ticket/7377#comment:130
https://trac.sagemath.org/ticket/7377#comment:130
<p>
Hmm, that shouldn't be failing now that JP put that back in - it was fine for me. Did you use <a class="attachment" href="https://trac.sagemath.org/attachment/ticket/7377/trac_7377-doctests-p1.patch" title="Attachment 'trac_7377-doctests-p1.patch' in Ticket #7377">attachment:trac_7377-doctests-p1.patch</a><a class="trac-rawlink" href="https://trac.sagemath.org/raw-attachment/ticket/7377/trac_7377-doctests-p1.patch" title="Download"></a> or <a class="attachment" href="https://trac.sagemath.org/attachment/ticket/7377/trac_7377-doctests-p2.patch" title="Attachment 'trac_7377-doctests-p2.patch' in Ticket #7377">attachment:trac_7377-doctests-p2.patch</a><a class="trac-rawlink" href="https://trac.sagemath.org/raw-attachment/ticket/7377/trac_7377-doctests-p2.patch" title="Download"></a> (either of these should be fine) instead of <a class="attachment" href="https://trac.sagemath.org/attachment/ticket/7377/trac_7377-doctests.patch" title="Attachment 'trac_7377-doctests.patch' in Ticket #7377">attachment:trac_7377-doctests.patch</a><a class="trac-rawlink" href="https://trac.sagemath.org/raw-attachment/ticket/7377/trac_7377-doctests.patch" title="Download"></a> (bad)?
</p>
TicketfbisseyThu, 17 Mar 2011 01:09:52 GMT
https://trac.sagemath.org/ticket/7377#comment:131
https://trac.sagemath.org/ticket/7377#comment:131
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/7377#comment:130" title="Comment 130">kcrisman</a>:
</p>
<blockquote class="citation">
<p>
Hmm, that shouldn't be failing now that JP put that back in - it was fine for me. Did you use <a class="attachment" href="https://trac.sagemath.org/attachment/ticket/7377/trac_7377-doctests-p1.patch" title="Attachment 'trac_7377-doctests-p1.patch' in Ticket #7377">attachment:trac_7377-doctests-p1.patch</a><a class="trac-rawlink" href="https://trac.sagemath.org/raw-attachment/ticket/7377/trac_7377-doctests-p1.patch" title="Download"></a> or <a class="attachment" href="https://trac.sagemath.org/attachment/ticket/7377/trac_7377-doctests-p2.patch" title="Attachment 'trac_7377-doctests-p2.patch' in Ticket #7377">attachment:trac_7377-doctests-p2.patch</a><a class="trac-rawlink" href="https://trac.sagemath.org/raw-attachment/ticket/7377/trac_7377-doctests-p2.patch" title="Download"></a> (either of these should be fine) instead of <a class="attachment" href="https://trac.sagemath.org/attachment/ticket/7377/trac_7377-doctests.patch" title="Attachment 'trac_7377-doctests.patch' in Ticket #7377">attachment:trac_7377-doctests.patch</a><a class="trac-rawlink" href="https://trac.sagemath.org/raw-attachment/ticket/7377/trac_7377-doctests.patch" title="Download"></a> (bad)?
</p>
</blockquote>
<p>
Not sure what the problem was. I did a bit of rewriting on how I apply the patches in sage-on-gentoo to make it a bit more transparent. Reapplied all the patches, rebuild and now the test looks fine
</p>
<pre class="wiki">sage -t -long -force_lib "devel/sage-main/sage/symbolic/integration/integral.py"
[4.6 s]
----------------------------------------------------------------------
All tests passed!
Total time for all tests: 4.6 seconds
</pre><p>
So I am OK with it :)
At last!
</p>
TicketkcrismanThu, 17 Mar 2011 01:59:06 GMT
https://trac.sagemath.org/ticket/7377#comment:132
https://trac.sagemath.org/ticket/7377#comment:132
<p>
It looks like then the only thing that remains is to officially review JP's refactoring of expect/interface and !maxima_abstract/maxima/maxima_lib. I am comfortable with it, and have checked the outlines of the refactoring which are more than satisfactory, but simply have not had the time (and will not) to go over that with a fine-toothed comb to check whether there is some missing function.
</p>
<p>
Presumably not! Since we never remove doctests, right? So in my opinion it's ready for positive review, since the interfaces to GAP and R and Pari etc. are used heavily elsewhere in Sage, so it's not like the interface stuff isn't tested (not to mention the Maxima stuff, of course, but that is not what is at issue here). Still, maybe someone else wants to comment on this. Otherwise we should be sure we get this in 4.7, before bitrot sets in.
</p>
TicketjpfloriThu, 17 Mar 2011 08:24:24 GMT
https://trac.sagemath.org/ticket/7377#comment:133
https://trac.sagemath.org/ticket/7377#comment:133
<p>
The principal stuff should indeed be ok with the doctests p1 or p2 patch.
</p>
<p>
For patchbot which does not seem to read or understand the desciption:
</p>
<p>
Depends on <a class="closed ticket" href="https://trac.sagemath.org/ticket/10766" title="defect: Update ECL to the latest upstream release. (closed: fixed)">#10766</a>, <a class="closed ticket" href="https://trac.sagemath.org/ticket/10773" title="enhancement: Update Maxima to the latest upstream release. (closed: fixed)">#10773</a>, <a class="closed ticket" href="https://trac.sagemath.org/ticket/10743" title="enhancement: Add iterator protocol to EclObject (closed: fixed)">#10743</a>. Ticket <a class="closed ticket" href="https://trac.sagemath.org/ticket/10818" title="defect: EclLib should allow signals to make LISP code interruptable (closed: fixed)">#10818</a> is desirable but not essential.<br /> Apply trac_7377-abstract-maxima_p2.patch, trac_7377-maximalib_p2.patch, trac_7377-fastcalculus_p2.patch, trac_7377-better-ask-error_p2.patch, trac_7377-split_and_refactor-p2.patch, trac_7377-lazy-maxlib.p2.patch, trac_7377-floatcast.patch, trac_7377-unicode_to_ecl-p1.patch, trac_7377-assumptions-p3.patch, trac_7377-doctests-p2.patch
</p>
TicketfbisseyThu, 17 Mar 2011 08:37:59 GMTdescription changed
https://trac.sagemath.org/ticket/7377#comment:134
https://trac.sagemath.org/ticket/7377#comment:134
<ul>
<li><strong>description</strong>
modified (<a href="/ticket/7377?action=diff&version=134">diff</a>)
</li>
</ul>
<p>
Let's try a bit of cleaning.
</p>
TicketnbruinSat, 19 Mar 2011 20:57:15 GMT
https://trac.sagemath.org/ticket/7377#comment:135
https://trac.sagemath.org/ticket/7377#comment:135
<p>
I would definitely give the bits I haven't written a positive review. Great work, JP and KDC! Thank you very much for finishing off this project. Your knowledge of the system was definitely required to get the last bits right.
</p>
TicketfbisseySat, 19 Mar 2011 21:06:36 GMTstatus, description, author changed
https://trac.sagemath.org/ticket/7377#comment:136
https://trac.sagemath.org/ticket/7377#comment:136
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>positive_review</em>
</li>
<li><strong>description</strong>
modified (<a href="/ticket/7377?action=diff&version=136">diff</a>)
</li>
<li><strong>author</strong>
changed from <em>Nils Bruin, Jean-Pierre Flori</em> to <em>Nils Bruin, Jean-Pierre Flori, Karl-Dieter Crisman</em>
</li>
</ul>
<p>
I am adding Karl to the list of authors, do a little fiddling and take the responsibility of switching that to positive review. I think we have a large consensus among the people involved that this works. Now is the time to have a bigger test.
</p>
TicketkcrismanSun, 20 Mar 2011 00:42:08 GMT
https://trac.sagemath.org/ticket/7377#comment:137
https://trac.sagemath.org/ticket/7377#comment:137
<p>
That is extremely gracious of you - I don't feel like I did much. I definitely agree about the consensus and time to have a bigger test. Hopefully it will end up in alpha2 or alpha3.
</p>
TicketfbisseySun, 20 Mar 2011 00:52:52 GMT
https://trac.sagemath.org/ticket/7377#comment:138
https://trac.sagemath.org/ticket/7377#comment:138
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/7377#comment:137" title="Comment 137">kcrisman</a>:
</p>
<blockquote class="citation">
<p>
That is extremely gracious of you - I don't feel like I did much. I definitely agree about the consensus and time to have a bigger test. Hopefully it will end up in alpha2 or alpha3.
</p>
</blockquote>
<p>
Not at all. You contributed, even if it has been revised by someone else afterwards. I doubt very much it will be in alpha2. I think (gut feeling) that Jeroen wants to have alpha2 out soon and won't add something that will delay it further.
</p>
<p>
I am not sure about alpha3 either, it is a big change. He may object to it for 4.7 altogether. In any case we'll be ready to be picked up at the next opportunity.
</p>
TicketnbruinWed, 30 Mar 2011 11:23:26 GMTauthor changed
https://trac.sagemath.org/ticket/7377#comment:139
https://trac.sagemath.org/ticket/7377#comment:139
<ul>
<li><strong>author</strong>
changed from <em>Nils Bruin, Jean-Pierre Flori, Karl-Dieter Crisman</em> to <em>Robert Bradshaw, Nils Bruin, Jean-Pierre Flori, Karl-Dieter Crisman</em>
</li>
</ul>
TicketnbruinWed, 30 Mar 2011 11:26:27 GMT
https://trac.sagemath.org/ticket/7377#comment:140
https://trac.sagemath.org/ticket/7377#comment:140
<p>
Added Robert Bradshaw to authors. He did the original splitting of the maxima_abstract interface, which was instrumental to making this project doable. JP can probably judge how much of Robert's work remained after his refactoring and is welcome to reverse this change if he feels that to be appropriate.
</p>
TicketjdemeyerFri, 01 Apr 2011 12:27:37 GMTstatus, milestone changed
https://trac.sagemath.org/ticket/7377#comment:141
https://trac.sagemath.org/ticket/7377#comment:141
<ul>
<li><strong>status</strong>
changed from <em>positive_review</em> to <em>needs_work</em>
</li>
<li><strong>milestone</strong>
changed from <em>sage-feature</em> to <em>sage-4.7</em>
</li>
</ul>
<p>
Please rebase:
</p>
<pre class="wiki">applying /scratch/jdemeyer/merger/downloads/trac_7377-split_and_refactor-p2.patch
patching file sage/interfaces/expect.py
Hunk #13 FAILED at 1025
Hunk #17 FAILED at 1285
Hunk #18 FAILED at 1339
</pre>
TicketjpfloriFri, 01 Apr 2011 15:20:59 GMTstatus, description changed
https://trac.sagemath.org/ticket/7377#comment:142
https://trac.sagemath.org/ticket/7377#comment:142
<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/7377?action=diff&version=142">diff</a>)
</li>
</ul>
<p>
I rebased the patches against sage 4.7.alpha3.
I could run make ptestlong yet because upgrade from 4.6.2 failed (givaro problem) and the binary provided for 4.7.alpha3 would not run (some liblapack problem).
However it should apply cleanly.
I'm building 4.7.alpha3 from source and will test when finished.
</p>
TicketjdemeyerMon, 04 Apr 2011 08:22:35 GMTstatus changed
https://trac.sagemath.org/ticket/7377#comment:143
https://trac.sagemath.org/ticket/7377#comment:143
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>needs_work</em>
</li>
</ul>
<p>
After applying this patch, everything compiles but Sage doesn't run properly:
</p>
<pre class="wiki">$ ./sage
----------------------------------------------------------------------
| Sage Version 4.7.alpha0, Release Date: 2011-03-04 |
| Type notebook() for the GUI, and license() for information. |
----------------------------------------------------------------------
**********************************************************************
* *
* Warning: this is a prerelease version, and it may be unstable. *
* *
**********************************************************************
---------------------------------------------------------------------------
ImportError Traceback (most recent call last)
/mnt/usb1/scratch/jdemeyer/merger/sage-4.7.alpha4/local/lib/python2.6/site-packages/IPython/ipmaker.pyc in force_import(modname)
64 reload(sys.modules[modname])
65 else:
---> 66 __import__(modname)
67
68
/mnt/usb1/scratch/jdemeyer/merger/sage-4.7.alpha4/local/bin/ipy_profile_sage.py in <module>()
5 preparser(True)
6
----> 7 import sage.all_cmdline
8 sage.all_cmdline._init_cmdline(globals())
9
/mnt/usb1/scratch/jdemeyer/merger/sage-4.7.alpha4/local/lib/python2.6/site-packages/sage/all_cmdline.py in <module>()
12 try:
13
---> 14 from sage.all import *
15 from sage.calculus.predefined import x
16 preparser(on=True)
/mnt/usb1/scratch/jdemeyer/merger/sage-4.7.alpha4/local/lib/python2.6/site-packages/sage/all.py in <module>()
57 from time import sleep
58
---> 59 from sage.misc.all import * # takes a while
60
61 from sage.misc.sh import sh
/mnt/usb1/scratch/jdemeyer/merger/sage-4.7.alpha4/local/lib/python2.6/site-packages/sage/misc/all.py in <module>()
77 from func_persist import func_persist
78
---> 79 from functional import (additive_order,
80 sqrt as numerical_sqrt,
81 arg,
/mnt/usb1/scratch/jdemeyer/merger/sage-4.7.alpha4/local/lib/python2.6/site-packages/sage/misc/functional.py in <module>()
32 import sage.misc.latex
33 import sage.server.support
---> 34 import sage.interfaces.expect
35 import sage.interfaces.mathematica
36
/mnt/usb1/scratch/jdemeyer/merger/sage-4.7.alpha4/local/lib/python2.6/site-packages/sage/interfaces/expect.py in <module>()
56 import pexpect
57 from pexpect import ExceptionPexpect
---> 58 from sage.interfaces.interface import Interface, InterfaceElement, InterfaceFunction, InterfaceFunctionElement, AsciiArtString
59
60 from sage.structure.sage_object import SageObject
ImportError: No module named interface
Error importing ipy_profile_sage - perhaps you should run %upgrade?
WARNING: Loading of ipy_profile_sage failed.
sage:
</pre>
TicketfbisseyMon, 04 Apr 2011 10:08:26 GMT
https://trac.sagemath.org/ticket/7377#comment:144
https://trac.sagemath.org/ticket/7377#comment:144
<p>
interface.py is missing in the trac_7377-split_and_refactor-p3.patch, it must have been overlooked. That's the cause of the problem.
</p>
TicketjpfloriMon, 04 Apr 2011 10:47:30 GMTattachment set
https://trac.sagemath.org/ticket/7377
https://trac.sagemath.org/ticket/7377
<ul>
<li><strong>attachment</strong>
set to <em>trac_7377-doctests-p3.patch</em>
</li>
</ul>
<p>
Rebased on Sage 4.7.alpha3, put back forgotten interface.py
</p>
TicketjdemeyerMon, 04 Apr 2011 20:57:48 GMTstatus changed
https://trac.sagemath.org/ticket/7377#comment:145
https://trac.sagemath.org/ticket/7377#comment:145
<ul>
<li><strong>status</strong>
changed from <em>needs_work</em> to <em>needs_review</em>
</li>
</ul>
<p>
Currently, there is a patch at <a class="closed ticket" href="https://trac.sagemath.org/ticket/10818" title="defect: EclLib should allow signals to make LISP code interruptable (closed: fixed)">#10818</a> (ECL interrupts) which needs review. Is anyone able to review that?
</p>
TicketjdemeyerTue, 05 Apr 2011 07:49:45 GMTstatus changed
https://trac.sagemath.org/ticket/7377#comment:146
https://trac.sagemath.org/ticket/7377#comment:146
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>needs_work</em>
</li>
</ul>
<p>
Doctest failures most likely caused by this patch:
</p>
<pre class="wiki">sage -t -force_lib devel/sage/sage/misc/sage_eval.py
**********************************************************************
File "/mnt/usb1/scratch/jdemeyer/merger/sage-4.7.alpha4/devel/sage-main/sage/misc/sage_eval.py", line 237:
sage: a._sage_()
Exception raised:
Traceback (most recent call last):
File "/mnt/usb1/scratch/jdemeyer/merger/sage-4.7.alpha4/local/bin/ncadoctest.py", line 1231, in run_one_test
self.run_one_example(test, example, filename, compileflags)
File "/mnt/usb1/scratch/jdemeyer/merger/sage-4.7.alpha4/local/bin/sagedoctest.py", line 38, in run_one_example
OrigDocTestRunner.run_one_example(self, test, example, filename, compileflags)
File "/mnt/usb1/scratch/jdemeyer/merger/sage-4.7.alpha4/local/bin/ncadoctest.py", line 1172, in run_one_example
compileflags, 1) in test.globs
File "<doctest __main__.example_2[12]>", line 1, in <module>
a._sage_()###line 237:
sage: a._sage_()
File "/mnt/usb1/scratch/jdemeyer/merger/sage-4.7.alpha4/local/lib/python/site-packages/sage/interfaces/interface.py", line 855, in _sage_
raise NotImplementedError, "Unable to parse output: %s" % string
NotImplementedError: Unable to parse output: 313131/811
**********************************************************************
</pre><pre class="wiki">sage -t -force_lib devel/sage/sage/groups/perm_gps/permgroup.py
**********************************************************************
File "/mnt/usb1/scratch/jdemeyer/merger/sage-4.7.alpha4/devel/sage-main/sage/groups/perm_gps/permgroup.py", line 881:
sage: G.orbits()
Exception raised:
Traceback (most recent call last):
File "/mnt/usb1/scratch/jdemeyer/merger/sage-4.7.alpha4/local/bin/ncadoctest.py", line 1231, in run_one_test
self.run_one_example(test, example, filename, compileflags)
File "/mnt/usb1/scratch/jdemeyer/merger/sage-4.7.alpha4/local/bin/sagedoctest.py", line 38, in run_one_example
OrigDocTestRunner.run_one_example(self, test, example, filename, compileflags)
File "/mnt/usb1/scratch/jdemeyer/merger/sage-4.7.alpha4/local/bin/ncadoctest.py", line 1172, in run_one_example
compileflags, 1) in test.globs
File "<doctest __main__.example_26[3]>", line 1, in <module>
G.orbits()###line 881:
sage: G.orbits()
File "/mnt/usb1/scratch/jdemeyer/merger/sage-4.7.alpha4/local/lib/python/site-packages/sage/misc/cachefunc.py", line 555, in __call__
w = self._cachedmethod._instance_call(self._instance, *args, **kwds)
File "/mnt/usb1/scratch/jdemeyer/merger/sage-4.7.alpha4/local/lib/python/site-packages/sage/misc/cachefunc.py", line 778, in _instance_call
return self._cachedfunc.f(inst, *args, **kwds)
File "/mnt/usb1/scratch/jdemeyer/merger/sage-4.7.alpha4/local/lib/python/site-packages/sage/groups/perm_gps/permgroup.py", line 896, in orbits
return self._gap_().Orbits("[1..%d]" % self.largest_moved_point()).sage()
File "/mnt/usb1/scratch/jdemeyer/merger/sage-4.7.alpha4/local/lib/python/site-packages/sage/interfaces/interface.py", line 869, in sage
return self._sage_()
File "/mnt/usb1/scratch/jdemeyer/merger/sage-4.7.alpha4/local/lib/python/site-packages/sage/interfaces/interface.py", line 855, in _sage_
raise NotImplementedError, "Unable to parse output: %s" % string
NotImplementedError: Unable to parse output: [ [ 1, 3, 4 ], [ 2 ] ]
**********************************************************************
[...lots more...]
</pre>
TicketfbisseyTue, 05 Apr 2011 08:50:18 GMT
https://trac.sagemath.org/ticket/7377#comment:147
https://trac.sagemath.org/ticket/7377#comment:147
<p>
Got the same failures here.
</p>
TicketjpfloriTue, 05 Apr 2011 08:59:36 GMT
https://trac.sagemath.org/ticket/7377#comment:148
https://trac.sagemath.org/ticket/7377#comment:148
<p>
That's because of split_and_refactor (at least from p2, strange it did not occur before).
Hopefully I fixed it.
I'm currently trying to run make ptestlong.
I'll post the patch this afternoon.
</p>
TicketjpfloriTue, 05 Apr 2011 11:05:37 GMTattachment set
https://trac.sagemath.org/ticket/7377
https://trac.sagemath.org/ticket/7377
<ul>
<li><strong>attachment</strong>
set to <em>trac_7377-split_and_refactor-p3.patch</em>
</li>
</ul>
<p>
Rebased on Sage 4.7.alpha3, put back forgotten interface.py
</p>
TicketjpfloriTue, 05 Apr 2011 11:07:18 GMTstatus changed
https://trac.sagemath.org/ticket/7377#comment:149
https://trac.sagemath.org/ticket/7377#comment:149
<ul>
<li><strong>status</strong>
changed from <em>needs_work</em> to <em>needs_review</em>
</li>
</ul>
<p>
It should be ok now. It applied against 4.7.alpha3 and ran make ptestlong:
</p>
<pre class="wiki">----------------------------------------------------------------------
All tests passed!
Total time for all tests: 2519.7 seconds
</pre>
TicketjpfloriWed, 06 Apr 2011 08:54:14 GMTdescription changed
https://trac.sagemath.org/ticket/7377#comment:150
https://trac.sagemath.org/ticket/7377#comment:150
<ul>
<li><strong>description</strong>
modified (<a href="/ticket/7377?action=diff&version=150">diff</a>)
</li>
</ul>
<p>
I was finally able to build 4.7.alpha3 from source (previous test was with prebuilt binary) and encountered no problem either.
</p>
<pre class="wiki">----------------------------------------------------------------------
All tests passed!
Total time for all tests: 2601.1 seconds
</pre>
TicketfbisseyWed, 06 Apr 2011 09:14:12 GMTstatus changed
https://trac.sagemath.org/ticket/7377#comment:151
https://trac.sagemath.org/ticket/7377#comment:151
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>positive_review</em>
</li>
</ul>
<p>
I did a new build against 4.7.alpha3 as well. And finally managed to test it.
So I am putting this back to positive review. Hopefully it won't be in vain.
</p>
TicketjdemeyerMon, 11 Apr 2011 19:15:47 GMTstatus changed; resolution, merged set
https://trac.sagemath.org/ticket/7377#comment:152
https://trac.sagemath.org/ticket/7377#comment:152
<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-4.7.alpha5</em>
</li>
</ul>
TicketjdemeyerThu, 14 Apr 2011 18:28:26 GMTstatus, milestone changed; resolution, merged deleted
https://trac.sagemath.org/ticket/7377#comment:153
https://trac.sagemath.org/ticket/7377#comment:153
<ul>
<li><strong>status</strong>
changed from <em>closed</em> to <em>new</em>
</li>
<li><strong>resolution</strong>
<em>fixed</em> deleted
</li>
<li><strong>merged</strong>
<em>sage-4.7.alpha5</em> deleted
</li>
<li><strong>milestone</strong>
changed from <em>sage-4.7</em> to <em>sage-4.7.1</em>
</li>
</ul>
<p>
Because of some issues with <a class="closed ticket" href="https://trac.sagemath.org/ticket/10818" title="defect: EclLib should allow signals to make LISP code interruptable (closed: fixed)">#10818</a> on Mac OS X and because of comments at <a class="closed ticket" href="https://trac.sagemath.org/ticket/10296" title="enhancement: Singular interface wasting time by waiting for the prompt too often (closed: fixed)">#10296</a>, my "gut" feeling says that maybe it is best to postpone this patch to the sage-4.7.1 cycle. I can't point at anything particular which is wrong, but I think it is not justified to merge this patchbomb at this point in the sage-4.7 cycle.
</p>
<p>
Of course, I remain open for arguments stating the contrary.
</p>
TicketjdemeyerThu, 14 Apr 2011 18:30:49 GMTstatus changed
https://trac.sagemath.org/ticket/7377#comment:154
https://trac.sagemath.org/ticket/7377#comment:154
<ul>
<li><strong>status</strong>
changed from <em>new</em> to <em>needs_review</em>
</li>
</ul>
TicketjdemeyerThu, 14 Apr 2011 18:31:00 GMTstatus changed
https://trac.sagemath.org/ticket/7377#comment:155
https://trac.sagemath.org/ticket/7377#comment:155
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>positive_review</em>
</li>
</ul>
TicketfbisseyThu, 14 Apr 2011 21:44:07 GMT
https://trac.sagemath.org/ticket/7377#comment:156
https://trac.sagemath.org/ticket/7377#comment:156
<p>
I'll admit that I was surprised you took that "patch bomb" in at all initially in alpha4 then alpha5. I am not completely sure but I think the new interface.py makes a number of components chatty. When I reviewed the test logs from my experiments with python-2.7 I have seen plenty of chatter of stuff going by pexpect that I don't remember being there before.
</p>
TicketkcrismanFri, 15 Apr 2011 00:57:38 GMT
https://trac.sagemath.org/ticket/7377#comment:157
https://trac.sagemath.org/ticket/7377#comment:157
<p>
Well, if that is the case then I guess this is wise. I do think that it's not appropriate to ask JP or Nils or anyone else to make more fixes until it's tested on a more wide basis by being in an alpha - as long as JP has time to rebase to 4.7, if that's necessary! 150+ comments is enough.
</p>
TicketjpfloriFri, 15 Apr 2011 06:23:34 GMTstatus changed
https://trac.sagemath.org/ticket/7377#comment:158
https://trac.sagemath.org/ticket/7377#comment:158
<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/7377#comment:156" title="Comment 156">fbissey</a>:
</p>
<blockquote class="citation">
<p>
I'll admit that I was surprised you took that "patch bomb" in at all initially in alpha4 then alpha5. I am not completely sure but I think the new interface.py makes a number of components chatty. When I reviewed the test logs from my experiments with python-2.7 I have seen plenty of chatter of stuff going by pexpect that I don't remember being there before.
</p>
</blockquote>
<p>
Could you tell me where to have a look for those chatty things ? Don't have much time to investigate that alone right now.
</p>
<p>
It is also a little bit surprising because the splitting of the expect class into expect and interface classes should be kind of trivial (just take a bunch of methods in expect and paste them in a superclass).
</p>
<p>
At least for most classes inheriting expect it should not have dramatic consequences. Of course I could have screwed up something in the way.
</p>
<p>
Both Maxima classes are more problematic because of multiple inheritance. It "works" now thanks to python MRO, but IIRC, that MRO will change with python 3.0 and could break everything.
</p>
TicketjpfloriFri, 15 Apr 2011 06:24:34 GMTwork_issues set
https://trac.sagemath.org/ticket/7377#comment:159
https://trac.sagemath.org/ticket/7377#comment:159
<ul>
<li><strong>work_issues</strong>
set to <em>investigate pexpect refactoring</em>
</li>
</ul>
TicketjdemeyerFri, 15 Apr 2011 08:10:34 GMT
https://trac.sagemath.org/ticket/7377#comment:160
https://trac.sagemath.org/ticket/7377#comment:160
<p>
I get the following error on SunOS 5.10-32 (marks) with a trial sage-4.7.alpha5. I'm sure whether the error is repeatable and whether it is related to this ticket, but I'm copying it here anyway:
</p>
<pre class="wiki">sage -t -long -force_lib devel/sage/sage/misc/trace.py
**********************************************************************
File "/home/buildbot/build/sage/mark2-1/mark_full/build/sage-4.7.alpha5/devel/sage-main/sage/misc/trace.py", line 54:
sage: _ = s.expect('100')
Exception raised:
Traceback (most recent call last):
File "/home/buildbot/build/sage/mark2-1/mark_full/build/sage-4.7.alpha5/local/bin/ncadoctest.py", line 1231, in run_one_test
self.run_one_example(test, example, filename, compileflags)
File "/home/buildbot/build/sage/mark2-1/mark_full/build/sage-4.7.alpha5/local/bin/sagedoctest.py", line 38, in run_one_example
OrigDocTestRunner.run_one_example(self, test, example, filename, compileflags)
File "/home/buildbot/build/sage/mark2-1/mark_full/build/sage-4.7.alpha5/local/bin/ncadoctest.py", line 1172, in run_one_example
compileflags, 1) in test.globs
File "<doctest __main__.example_1[6]>", line 1, in <module>
_ = s.expect('100')###line 54:
sage: _ = s.expect('100')
File "/home/buildbot/build/sage/mark2-1/mark_full/build/sage-4.7.alpha5/local/lib/python/site-packages/pexpect.py", line 912, in expect
return self.expect_list(compiled_pattern_list, timeout, searchwindowsize)
File "/home/buildbot/build/sage/mark2-1/mark_full/build/sage-4.7.alpha5/local/lib/python/site-packages/pexpect.py", line 989, in expect_list
raise TIMEOUT (str(e) + '\n' + str(self))
TIMEOUT: Timeout exceeded in read_nonblocking().
<pexpect.spawn instance at 0x32b4990>
version: 2.0 ($Revision: 1.151 $)
command: /home/buildbot/build/sage/mark2-1/mark_full/build/sage-4.7.alpha5/sage
args: ['/home/buildbot/build/sage/mark2-1/mark_full/build/sage-4.7.alpha5/sage']
patterns:
100
buffer (last 100 chars):
before (last 100 chars): *
**********************************************************************
after: <class 'pexpect.TIMEOUT'>
match: None
match_index: None
exitstatus: None
flag_eof: 0
pid: 24906
child_fd: 4
timeout: 30
delimiter: <class 'pexpect.EOF'>
logfile: None
maxread: 2000
searchwindowsize: None
delaybeforesend: 0.1
**********************************************************************
File "/home/buildbot/build/sage/mark2-1/mark_full/build/sage-4.7.alpha5/devel/sage-main/sage/misc/trace.py", line 61:
sage: print s.before[s.before.find('-'):]
Expected:
---...
ipdb> c
2 * 5
Got:
----------------------------------------------------------------------
| Sage Version 4.7.alpha5, Release Date: 2011-04-13 |
| Type notebook() for the GUI, and license() for information. |
----------------------------------------------------------------------
**********************************************************************
* *
* Warning: this is a prerelease version, and it may be unstable. *
* *
**********************************************************************
<BLANKLINE>
**********************************************************************
1 items had failures:
2 of 11 in __main__.example_1
</pre>
TicketfbisseyFri, 15 Apr 2011 08:59:18 GMT
https://trac.sagemath.org/ticket/7377#comment:161
https://trac.sagemath.org/ticket/7377#comment:161
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/7377#comment:158" title="Comment 158">jpflori</a>:
</p>
<blockquote class="citation">
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/7377#comment:156" title="Comment 156">fbissey</a>:
</p>
<blockquote class="citation">
<p>
I'll admit that I was surprised you took that "patch bomb" in at all initially in alpha4 then alpha5. I am not completely sure but I think the new interface.py makes a number of components chatty. When I reviewed the test logs from my experiments with python-2.7 I have seen plenty of chatter of stuff going by pexpect that I don't remember being there before.
</p>
</blockquote>
<p>
Could you tell me where to have a look for those chatty things ? Don't have much time to investigate that alone right now.
</p>
</blockquote>
<p>
I have posted a log at <a class="closed ticket" href="https://trac.sagemath.org/ticket/9958" title="enhancement: Upgrade python to 2.7.x (closed: fixed)">#9958</a> (sage-4.7.alpha4-test.log.bz2) look for mwrank.py for example.
</p>
TicketjpfloriFri, 15 Apr 2011 09:29:18 GMT
https://trac.sagemath.org/ticket/7377#comment:162
https://trac.sagemath.org/ticket/7377#comment:162
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/7377#comment:161" title="Comment 161">fbissey</a>:
</p>
<blockquote class="citation">
<p>
I have posted a log at <a class="closed ticket" href="https://trac.sagemath.org/ticket/9958" title="enhancement: Upgrade python to 2.7.x (closed: fixed)">#9958</a> (sage-4.7.alpha4-test.log.bz2) look for mwrank.py for example.
</p>
</blockquote>
<p>
Are you sure that mwrank is related in any way to the expect.py/interface.py we've modified here ?
</p>
<p>
mwrank.pyx provides access to a C++ library and the interface.py in the same folder just provides direct python access to methods defined in the first file or am I completely missing something here ?
</p>
TicketjpfloriFri, 15 Apr 2011 09:41:41 GMT
https://trac.sagemath.org/ticket/7377#comment:163
https://trac.sagemath.org/ticket/7377#comment:163
<p>
I've search through the logs for "interfaces" (the main directory wa are concerned with), "calculus" and "symbolic".
</p>
<p>
The only noise I found so far is:
</p>
<pre class="wiki">File "/usr/share/sage/devel/sage-main/sage/symbolic/expression.pyx", line 7728:
sage: f = 1 + x + sqrt(x+2); f.find_root(-2,10)
Expected:
-1.6180339887498949
Got:
-1.618033988749895
#0: simplify_sum(expr='sum(q^k,k,0,inf))
#1: simplify_sum(expr=a*'sum(q^k,k,0,inf))
</pre><p>
and:
</p>
<pre class="wiki">File "/usr/share/sage/devel/sage-main/sage/calculus/calculus.py", line 223:
sage: float(z)
Expected:
4.6467837624329356
Got:
4.646783762432936
#0: simplify_sum(expr='sum(q^k,k,0,inf))
#1: simplify_sum(expr=a*'sum(q^k,k,0,inf))
</pre><p>
Which does not cause any problem if the doctest passes (i.e. if we set the expected answer to the correct precision).
</p>
<p>
It's caused in some way by ECL (I've tried to redirect as much as possible toward "/dev/null" slightly modifying the first version of the patches but could not get better result, I'm no expert in Lisp) and not by the refactoring of expect.py into expect.py/interface.py
</p>
TicketfbisseyFri, 15 Apr 2011 20:00:48 GMT
https://trac.sagemath.org/ticket/7377#comment:164
https://trac.sagemath.org/ticket/7377#comment:164
<p>
OK, no problem Jean-Pierre. There are a lot of things going on with python 2.7 that may just be one of them. I thought the mwrank executable was called by the expect interface. There probably wouldn't be anything to spot if it weren't for all these doctests failures. It doesn't cause the test failure either I think.
</p>
TicketjpfloriFri, 22 Apr 2011 09:50:23 GMT
https://trac.sagemath.org/ticket/7377#comment:165
https://trac.sagemath.org/ticket/7377#comment:165
<p>
I definitely think the mwrank problem is complete unrelated to this ticket.
</p>
<p>
Could someone repoduce Jeroen bug ? I've got no problems on my debian amd64 with 4.7.alpha3, but I won't have the time to build the latest alpha today or next week, nor working on this ticket, but is there anything preventing it to go back to needs_review or even positive_review ?
</p>
TicketjdemeyerMon, 25 Apr 2011 10:03:49 GMT
https://trac.sagemath.org/ticket/7377#comment:166
https://trac.sagemath.org/ticket/7377#comment:166
<p>
<a class="ext-link" href="http://trac.sagemath.org/sage_trac/ticket/7377#comment:160"><span class="icon"></span>This bug</a> is most likely <strong>not</strong> related to this ticket.
</p>
TicketjpfloriMon, 25 Apr 2011 16:02:26 GMTstatus changed; work_issues deleted
https://trac.sagemath.org/ticket/7377#comment:167
https://trac.sagemath.org/ticket/7377#comment:167
<ul>
<li><strong>status</strong>
changed from <em>needs_work</em> to <em>needs_review</em>
</li>
<li><strong>work_issues</strong>
<em>investigate pexpect refactoring</em> deleted
</li>
</ul>
TicketfbisseyMon, 25 Apr 2011 19:41:55 GMTstatus changed
https://trac.sagemath.org/ticket/7377#comment:168
https://trac.sagemath.org/ticket/7377#comment:168
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>positive_review</em>
</li>
</ul>
<p>
I think we are now clear. The chattiness is likely to come from somewhere else and Jeroen says his bug is probably unrelated. I'll put that back to positive review - again.
</p>
TicketjdemeyerTue, 26 Apr 2011 09:05:15 GMTstatus changed; resolution, merged set
https://trac.sagemath.org/ticket/7377#comment:169
https://trac.sagemath.org/ticket/7377#comment:169
<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-4.7.1.alpha0</em>
</li>
</ul>
Ticket