On 8/10/07, Timothy Clemans <[EMAIL PROTECTED]> wrote:
> What version of SymPy is in SAGE 2.7.3? It would be nice if it was
> easy to find out what version of SymPy is installed in a given SAGE
> install.
>
Sympy provides that info:
sage: import sympy
sage: sympy.__version__
'0.4.2'
This is sometimes not set correctly by the sympy people though.
The next SAGE release (sage-2.8) will include the latest released
version of Sympy.
You can always also tell by looking at
ls SAGE_ROOT/spkg/installed/sympy*
Also, you can do
sage -i sympy-0.4.3.spkg
to get the new version of Sympy, since I just posted it.
Finally, you can always just directly download the latest sympy, extract
it, and do this from the extracted directory:
sage -python setup.py install
to install it.
Looking at the sympy changelog, I think sympy development is moving rapidly
and in a good direction.
-- William
> On 8/10/07, William Stein <[EMAIL PROTECTED]> wrote:
> >
> > 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
> >
> > > >
> >
>
--
William Stein
Associate Professor of Mathematics
University of Washington
http://www.williamstein.org
--~--~---------~--~----~------------~-------~--~----~
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-support
URLs: http://sage.math.washington.edu/sage/ and http://sage.scipy.org/sage/
-~----------~----~----~----~------~----~------~--~---
