On 4/20/07, Ondrej Certik <[EMAIL PROTECTED]> wrote: > > > Let me know if you have trouble. I haven't used view much in the last year > > (I use the notebook more), so it might be somehow broken (??), as its > > hard to automatically test. > > I only tried the 2.4 binary version on debian unstable and it works > nice. Thanks. That's what I am going to do in sympy - to launch an > external program, so that it doesn't block the command line. And the > notebook is very nice. The tab completion, that works at sagenb.com > didn't work for me locally (it printed a tab instead) - is it a bug? > I would expect it to work according to the documentation: > http://modular.math.washington.edu/sage/doc/html/ref/node19.html
If tab completion doesn't work for you locally there is some sort of bug somewhere. Though there are no known (by me) bugs that would cause that problem. > > That sympy depends on pygame is painful, since pygame isn't > > trivial to install. When somebody recently was installing sympy > > into SAGE, they biggest issue was first installing pygame into SAGE > > (they did it, but it wasn't completely trivial). > > That is a bug, sympy shouldn't depend on anything besides a pure > python (2.4) installation. You should have written to the sympy > mailinglist, we would fix that. I think it is already fixed now, but > we'd better check it again. Cool -- I'm glad it's easy to install. I assume it also works fine with Python 2.5. Anyway, let me know when you guys have a new stable ready version, and I can make it an optional SAGE package, so it's trivial for any SAGE users to install sympy. > > SAGE makes no nontrivial use of either mathml or openmath. > > > > For latex output, all SAGE objects have an _latex_ method, sort > > of like Python's __repr__ method; every object can thus output > > itself in latex format directly -- there is no mathml intermediate. > > Likewise, to export an object to maxima, every SAGE object > > has a _maxima_init_ method that outputs a string that, when > > interpreted by Maxima, gives a corresponding object. Also, > > objects have a _maxima_ method that takes an instance of > > maxima and returns a Python classes of type MaximaElement > > that is a pointer to an actual object in a running instance > > of Maxima (and that object is cached, so subsequent calls > > return the same object -- moreover if the maxima session crashes > > the object is automatically recreated). All the statements above > > about maxima apply to the other dozen or so SAGE interfaces, e.g., > > to Maple, Magma, GAP, Singular, etc. (there are defaults for > > the various .._init_ methods in the base class...). > > > > To convert an arbitrary symbolic expression as output by maxima back to > > SAGE there is a function (new in SAGE-2.5) that sets up some variables, > > does some minimal preparsing, then uses Python's eval command on > > a string. Thus the conversion from maxima to Python is: > > > > maxima string repr --> slightly parsed version > > --> Python interpreter's eval --> Python object > > > > We have not written something like this (that works in general) for > > Maple or Mathematica yet, but Bobby Moretti is working on it right now. > > Thanks for the explanation. That's how it was originally in SymPy, > that every class (like sin, cos, Mul) can export itself to > latex/python/ascii art/etc., but the code was becoming quite cluttered > with this printing stuff, so we decided to export only mathml and we > added optional modules to convert it from mathml (which seemed to us > as a standard) to any other format. But I am actually not 100% > convinced that the mathml way is optimal - because the xsl stylesheets > are really ugly. Good luck with that. > And as to porting SymPy to SAGE - I wouldn't suggest to do it right > now, as currently SymPy is evolving too fast. But I guess at the end > of the summer it should be quite equipped with most things and the > interface will probably settle down. But I guess your calculus package > will be able to do the same things through maxima, so there will be no > need for porting SymPy anyway I think. Only if it turns out, that the > hybrid python+maxima is impossible to extend with new algorithms (for > limits, or integration, or differential equations, that maxima cannot > handle). It is extendable with new algorithms. It's just that the approach of making a hybrid python + maxima system gives us a CAS that is very powerful and full featured _today_ while minimizing the need to re-implement basic algorithms, at least until there is sufficient energy and funding to do so. It's not inconceivable that slowly but surely in the future many things in the SAGE CAS functionality that rely on Maxima right now will instead rely on either native Python code (e.g., via sympy), compiled SageX code, or something else (e.g., yacas, ginac, etc.). It's an iterative process. -- William --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to [email protected] 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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~----------~----~----~----~------~----~------~--~---
