On Mar 12, 2010, at 7:01 PM, Felix Lawrence wrote:

On Mar 12, 3:17 pm, Jason Grout <jason-s...@creativetrax.com> wrote:
So the Mathematica *input* syntax is closer to the sage *input* syntax, while the mathematica full form (i.e., the internal tree of operations)
is closer to the sage tree of operations.  That makes a lot of sense.
For software<->software translation, in the long run, it will probably
make more sense to hook up the two operation trees, rather than deal
with the sometimes vague output printing of one going into the input
printing of the other.

So we just need to hook the mathematica into a lower level of Sage (at
the pynac level) where the expressions are more consistent.

I would expect FullForm to be fairly consistent. Ideally, it would be transparent to the fact that we use Pynac under the hood to do our symbolics as well (especially as some of the stuff may not be symbolic expressions). Hooking it at the C level seems to brittle (not to mention license and testing issues).

I know very little about pynac, but isn't it designed specifically for
symbolic expressions?  How would you handle mathematica output that
isn't a symbolic expression?  Should we try to detect the type of
output and route it to pynac or whatever sage module is appropriate?
I don't think that I have enough knowledge about sage to do this - I'd
be much more comfortable writing a patch that just converts the repr()
and lets sage_eval (with an automatically generated locals dictionary)
sort it all out.  But if you'd like to write a patch working at a
lower level that converts both symbolic and numerical mathematica
results into pynac/numpy/whatever's appropriate, then I'll defer to
you!


It would be easy to write a FullForm parser. The number of "operations" that show up is probably much smaller as well--just match each of them to a callable in a dict (and perhaps trying to do a lookup on the standard set of functions by changing the case) and you're set. This also has the benefit of failing gracefully when something is not yet implemented.

- Robert

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Reply via email to