1. There is a public mathematica language parser (version 3.0 mathematica) that I wrote in common lisp. WRI knows about it, inquired about it, made various claims. I disputed them. They went away. This apparently has legal standing to the effect that they gave up so they must not feel it is in violation of their rights. But I am not a lawyer.
The mockmma parser can be found via google. It parses mathematica commands into lisp (morally equivalent to the internal lisp form of Maxima code, at least in the places they correspond. mockmma has lots more commands (including all of common lisp, in principle) than mathematica. 2. If Maxima's speed is an issue, Maxima can be made faster. One way is to use an implementation that is compiled. If CLISP, a byte-code interpreter is still being used by Sage, that would tend to slow the system down relative to a true compiler such as GCL, SBCL, Allegro, .... Another way to make Maxima faster is to profile important benchmarks and improve the code. There are several irons in the fire for some examples. Rewriting Maxima in python in an effort to make it faster has many things to dis-recommend it. But you don't want to hear them. 3. As Robert Dodier says, all those Maple features appear to be in Maxima. Perhaps they cannot escape from Maxima into Sage, which presumably has its own parser/representation/ ... issues. This, and a glance at his code, suggests that the original poster should be writing his code in Maxima, not Sage. An interesting commentary if in fact Sage, in this instance, is strictly less expressive than Maxima. RJF --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
