Thanks to some very helpful changes to the way that ECL uses GMP made
by Juanjo, it is now possible to interface ECL cleanly with SAGE as a
library. I have constructed a prototype. Patch is available at:

http://sage.math.washington.edu/home/nbruin/eclmax.patch

but you do need the CVS version of ECL for that and the instructions
on
http://trac.sagemath.org/sage_trac/ticket/6781
to build a maxima library. In addition:

ln -s $SAGE_LOCAL/lib/maxima/maxima.fasb $SAGE_LOCAL/lib/ecl-9.8.4/
maxima.fas

Alternatively, run on sage.math.washington.edu:

/scratch/nbruin/sage-newecl/sage

You can do something like:

sage: init_libmax()
;;; Loading #P"/scratch/nbruin/sage-newecl/local/lib/ecl-9.8.4/
maxima.fas"
sage: myint(x^2+x+1,x)
1/3*x^3 + 1/2*x^2 + x
sage: integrate(x^2+x+1,x)
1/3*x^3 + 1/2*x^2 + x
sage: timeit("myint(x^2+x+1,x)")
625 loops, best of 3: 552 µs per loop
sage: timeit("integrate(x^2+x+1,x)")
125 loops, best of 3: 9.28 ms per loop
sage:
sage: myint(1/(cos(x)^2),x) ##what's this?
SAGE_OP_2(x)
sage: SR_ops  ##ah, it didn't know how to translate TAN

{<built-in function add>: <ECL: MPLUS>,
 <built-in function mul>: <ECL: MTIMES>,
 <built-in function pow>: <ECL: MEXPT>,
 exp: <ECL: %EXP>,
 log: <ECL: %LOG>,
 sin: <ECL: %SIN>,
 cos: <ECL: %COS>,
 arctan: <ECL: %ATAN>,
 SAGE_OP_2: <ECL: %TAN>}
sage:
sage: a=SRtoMAX(sin(x)+cos(x))
sage: a
<ECL: ((MPLUS) ((%SIN) $SAGE-SYMBOL-1) ((%COS) $SAGE-SYMBOL-1))>
sage: x_MAX=SRtoMAX(x)
sage: i=MAXint(a,x_MAX)
sage: i

<ECL: ((MPLUS . #1=(SIMP)) ((MTIMES . #1#) -1 ((%COS . #2=(SIMP))
$SAGE-SYMBOL-1))
 ((%SIN . #2#) $SAGE-SYMBOL-1))>
sage: MAXtoSR(i)
sin(x) - cos(x)

At present, the wrapping is very incomplete and inefficient on the
sage side. The construction and traversing on the ECL side doesn't
look too inefficient (simpler interface).

I am sure that someone with more knowledge of how Pynac works can do a
much better job. I have also not been able yet to transport integers
between sage and ecl in an efficient way yet (this was because I
couldn't convince the C compiler that two mpz_t's were really of the
same type)

As shown above, the dictionaries currently available are only a rough
start. It also demonstrates that whenever an unknown symbol is
encountered on either side, the translator tries to come up with a
unique symbol to translate it into. Doing this often would lead to
exploding dictionaries. weakrefs or so?

Perhaps this experiment is useful for someone who wants to improve
integration or other functions that rely on interfacing with maxima

WARNING: ecl is written to provide only one instance of its workspace.
So whatever code is run will have to play nice with other components.
In particular, it is not possible to have two maxima instances running
in the same processes. I don't know how much global state maxima
relies on. Probably by carefully encoding symbols, this problem can be
minimized.

The interface above avoids Maxima's parser completely. Only atomic
quantities are constructed by the ECL reader (and that should largely
be avoidable too). Any lists are constructed using explicit library
calls to ecl_cons.

--~--~---------~--~----~------------~-------~--~----~
To post to this group, send an email to [email protected]
To unsubscribe from this group, send an email to 
[email protected]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---

Reply via email to