Symbolic Ring to Maxima via EclObject

[nbruin]

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).

Applies cleanly to 4.7.alpha3.

Depends on: #10766, #10773, #10743. #10818 desirable but not essential.

Apply:

• attachment: trac_7377-abstract-maxima_p2.patch
• attachment: trac_7377-maximalib_p2.patch
• attachment: trac_7377-fastcalculus_p2.patch
• attachment: trac_7377-better-ask-error_p2.patch
• attachment: trac_7377-split_and_refactor-p3.patch
• attachment: trac_7377-lazy-maxlib.p2.patch
• attachment: trac_7377-floatcast.patch
• attachment: trac_7377-unicode_to_ecl-p1.patch
• attachment: trac_7377-assumptions-p3.patch
• attachment: trac_7377-doctests-p3.patch

CC: @burcin @saliola @jpflori

Component: symbolics

Author: Robert Bradshaw, Nils Bruin, Jean-Pierre Flori, Karl-Dieter Crisman

Reviewer: Jean-Pierre Flori, François Bissey, Karl-Dieter Crisman, Nils Bruin

Merged: sage-4.7.1.alpha0

Issue created by migration from https://trac.sagemath.org/ticket/7377

[nbruin]

Attachment: sagemax.py.gz

example package for how to accomplish said interface

[nbruin]

I think the following email might be of interest to other people wanting to hack maxima:

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.

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.

There is max_read(S) = cadadr(EclObject("#$%s"%S)), which reads the string
S as a maxima expression and returns its parsed result.

So meval(max_read(S)) 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

max_read("maxima-command-to-print-to-string(x)")

and see what token the maxima reader puts in. I imagine you get something
like

<ECL: ((MAX-PRINT-STRING) x)>

back, So do:

maxprint:=EclObject("MAX-PRINT-STRING") #do this once globally
meval(EclObject([[maxprint], maxexpression])).python()

Indeed:

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'

So

sage: maxprint=EclObject("$STRING")
sage: def max_to_string(s):
....:      return meval(EclObject([[maxprint],s])).python()[1:-1]

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).

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

Yes, that would be an approach virtually orthogonal to the one taken in sagemax.py.

> 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);

To illustrate the inner workings:

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);

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.

[robertwb]

Attachment: 7377-abstract-maxima.patch.gz

[nbruin]

comment:3

Finally success! Recipe for getting calculus use
maxima in ecl library mode do the following

• apply the patch from Library access to ecl #6781
• apply Robert's 7377-abstract-maxima.patch
• apply maxlib.patch
  The calculus doctests currently fail because maxima asking questions does not get handled yet.

[nbruin]

comment:4

Updated maxlib.patch. Changes made:

• Code catches (throw 'macsyma-quit) and tries to recognise errors (often successful)
• suppress questions and throw errors instead
• suppress ";;; load ..." lines and load warnings
• set environment appropriately for calculus instance
  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.

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.

(the uploaded code has some diagnostic output in maxima_eval to try to debug the "forget" issues. The "ask" errors should just consist of updating the doctest.

Go at it!

[nbruin]

Maxima via library; used by calculus

[nbruin]

comment:5

Attachment: maxlib.patch.gz

Another update:

• change to symbolic/assumptions.py to not try: ... error: pass (gentler removal of assumptions makes the interface behave a bit better)

• monkey patch maxima to throw error on divergent integral instead of printing "Principal Value" and giving an answer.
  (maxima does behave as documented, so it is a matter of taste to change maxima's behaviour)

• slightly more pretty/informative error messages

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).

[kcrisman]

comment:7

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.

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.

Thanks to nbruin and robertwb for working so hard on this!