> -------------
> 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
> -----------
This is already fixed in the svn for some time, see the relevant issue
for details:
http://code.google.com/p/sympy/issues/detail?id=247
when we release the 0.5.0 soon, it will be included.
Note: all released versions use the old core, which was slow. The svn
version uses a new core, that is very fast, but it was a lot of work
to fix everything so that everything that used to work still works.
There are still some minor issues, that's why we didn't release for a
long time.
> 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.
Definitely, neither SAGE or SymPy should use Python ints (or floats),
because they are slow. In sympy/numerics (svn version), we have a
faster implementation of floats (in pure Python) that are much faster
than Python's Decimal, but it's not yet integrated in the core.
> 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 paragraph is just my own opinion:
For me, this is more confusing. The power of Python is, that it is a
standardised language that one can learn on many places on the web.
It's a great language, but it has some drawbacks (your examples
above). However, those drawbacks are well-known. By preparsing, you
are in fact creating a new language incompatible with Python and thus
it is very confusing. (I am not against sending a patch to python-dev
for implementing the features above in stock Python, then it would be
ok.) Imagine for example that I write some code using 1/3, or 2^3
(expecting 1/3 and 8 respectively), then I will not be able to run it
in Python and thus will get stuck in SAGE environment, which is (I
think) bad. So for SymPy, preparsing is unacceptable, for SAGE, since
it wants to be an environment and replacement for Maple/Mathematica,
maybe it makes sense, but still it is confusing to me.
> 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.,
Agree, we already fixed that. If it flies like a duck and looks like a
duck, it's a duck. So if it behaves like an Int..., it's an Int.
> 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.
_sympy_ could be implemented in SAGE to return SymPy expression, the
same way like _maxima_ works. But as I said above, the general Python
philosophy is not to check for int, but rather try to use it like int.
Thus what we do, is that we try to convert the expression to string
(which both Python and SAGE ints can do) and then we parse the string
to SymPy expression.
However, for more general conversion of complex expressions, the
_sympy_() method is probably needed.
> 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?
Sounds good. Also we can implement something in SymPy to help
converting back from SymPy to SAGE. For example _sage_ method, that
would return a SAGE expression (it would try to import SAGE at runtime
in the method _sage_, so that SymPy is not depending on anything else
besides Python).
Or maybe, since both SAGE and SymPy should be able to parse strings,
the _sympy_ and _sage_ methods can just return a string, and then it
will get parsed. That is probably the easiest and most clean solution
(maybe not the fastest).
> Sympy provides that info:
>
> sage: import sympy
> sage: sympy.__version__
> '0.4.2'
>
> This is sometimes not set correctly by the sympy people though.
Then it's a bug. We cannot do much with this one in already released
versions, but if you find some other problems (or just features that
you need and are missing), please report them in Issues (Issues tab on
the main SymPy page):
http://code.google.com/p/sympy/issues/list
Create a new issue and state the problem or a wish and we'll fix that,
or put that to our todo list.
Thanks,
Ondrej
--~--~---------~--~----~------------~-------~--~----~
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/
-~----------~----~----~----~------~----~------~--~---
