On Monday 26 November 2007 07:34, Ondrej Certik wrote:
> David Roe:
> > I would prefer that direction too. In order to make that happen, the
> > SymPy __add__ function has to recognize a sage element and call its
> > __add__ method instead. This sounds like it should be doable.
>
> I am not sure it's a clean solution. Ideally, neither SAGE nor SymPy
> should know about each other - of course both of them need to
> implement the
> _sage_ and _sympy_ methods (that of course need to know about the
> other), but that should be it.
I don't agree with this -- see below for my reasoning.
> Then you could plug any other library
> in SAGE, not just SymPy and it will work. If you look at the patch
> above:
>
> 373 elif isinstance(x, sympy.Basic):
> 374 #elif hasattr(x, "_sage_"):
> 375 # if "x" implements the _sage_() method, let's
> use it to convert
> 376 # the expression to a SAGE expression (for
> example SymPy provides
> 377 # _sage_() methods, some other libraries can
> too) 378 #
> 379 # unfortunately, the hasattr() above doesn't
> work (infinite 380 # recursion), so we check for SymPy
> directly. 381
> 382 return self(x._sage_())
>
> It should work just by checking for the _sage_ method, not trying if
> it is a SymPy object. Currently it doesn't, I get an infinite
> recursion, so it's commented out (but I consider this a bug).
>
> as to sympy('x') + SR(x) and SR(x) + sympy('x'):
>
> it can be more complicated, like this:
>
> SR(x) + SR(y) + sympy(x) and sympy(x)+sympy(y)+SR(x)
>
> so you propose, that whenever there is some SAGE expression inside the
> sympy expression, the result should be a SAGE expression? That seems
> reasonable, but how about this:
>
> sympy.sin(SR(x))
I want results of operations with sage objects to be sage objects. This is
the same as it is with python objects now:
sage_int+python_int=python_int+sage_int=sage_int
Very simply, this is because I'm a sage user not a sympy user. I think that
the sage SymbolicExpressionRing needs to have the extra functionality to
properly wrap (i.e. in a sage-ish way) the sympy functionality. If we want
to use sympy as a back-end to implement these things (much like we do with
maxima), that's great. I realize that this is probably a longer term goal.
If we need a sub-optimal fix along the journey to get there, that may be
fine.
Sorry Ondrej, I certainly don't mean this as a strike against sympy. I think
it's a great project and I want sage and sympy to co-exist. However, one of
the beautiful things about sage (to me at least) is the pristine consistent
object hierarchy which neatly masks the many pieces behind it. I don't want
that compromised.
(In reality, I think that sympy and sage should simply merge. However, I
don't know enough about sympy to know how feasible that is. I put this in
parenthesis, because I fear it's kind of a demeaning thing to say. I don't
mean it that way though. It just feels like they are natural complements of
each other. The whole would be greater than the sum of it's parts.)
--
Joel
--~--~---------~--~----~------------~-------~--~----~
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/
-~----------~----~----~----~------~----~------~--~---
