Hi, I gave a talk here
http://www.cecm.sfu.ca/events/CECM07/index.shtml about SAGE (=use Python for math) on Wednesday; it was in Canada, and the audience was almost entirely heavy Maple users. Interestingly, the second question I got from a professor in the audience was "do you know about Sympy? I use it in some of my math modeling work." i was of course, happy to remark that Sympy is included standard in SAGE. Now that Sympy is in SAGE, I'd like using Sympy from SAGE to be as easy as possible. The first natural thing to attempt would be to get the following to work: ------------- sage: from sympy import * sage: x = Symbol(1) sage: x + 1 --------------------------------------------------------------------------- <type 'exceptions.ValueError'> Traceback (most recent call last) /home/was/s/spkg/standard/<ipython console> in <module>() /home/was/s/local/lib/python2.5/site-packages/sympy/core/basic.py in __add__(self, a) 244 def __add__(self,a): 245 from addmul import Add --> 246 return Add(self, self.sympify(a)) 247 248 def __radd__(self,a): /home/was/s/local/lib/python2.5/site-packages/sympy/core/basic.py in sympify(a) 527 else: 528 if not isinstance(a,Basic): --> 529 raise ValueError("%s must be a subclass of basic" % str(a)) 530 return a 531 <type 'exceptions.ValueError'>: 1 must be a subclass of basic ----------- In SAGE, the expression 'x + 1' is replaced by 'x+Integer(1)' before being evaluated by Python, where Integer(1) creates a GMP-based Integer, that is implemented as a very highly optimized Cython (http://cython.org) extension class. sage: preparse('x+1') 'x+Integer(1)' Some reasons this sort of minimal preparsing is done in SAGE include: 1. As soon as integers get at all large (bigger than three machine words, say), SAGE's GMP-based integer type is much faster than Python's builtin arbitrary precision integer type. 2. We want the following to behave different than in Python, to avoid lots of confusion to mathematicians: sage: 1/3 1/3 sage: 2^3 8 versus >>> 1/3 0 >>> 2^3 1 This brings me to the example above. The SAGE Integer type is not a builtin Python numeric type, and it doesn't derive from Sympy's "basic" class. Thus Sympy just gives up on it for arithmetic. This is very bad for me. Would you consider, e.g., calling a method to convert an arbitrary object to a Sympy object instead of giving up with an error. For example, before raising ValueError here: 528 if not isinstance(a,Basic): --> 529 raise ValueError("%s must be a subclass of basic" % str(a)) 530 return a you could instead check for an _sympy_ method, and if it is there call that. Then I could add a method like this to my Integer class (and likewise for many other SAGE classes), and SAGE and Sympy would then work well together again: def _sympy_(self): return something sympy is happy to work with. The same approach could also work for symbolic calculus expressions -- in SAGE one can input very complicated formal symbolic expressions, and if they had a _sympy_ method, it would be easy to use them with Sympy functions. What do you think? -- William -- William Stein Associate Professor of Mathematics University of Washington http://www.williamstein.org --~--~---------~--~----~------------~-------~--~----~ 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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~----------~----~----~----~------~----~------~--~---
