> I don't think so, since probably sage/maxima have special functions
> sympy doesn't. And even if it could be, the functions provided by
> SymPy are different
> than the ones provided by SymbolicRing.
>
> If sympy('x') + x and x + sympy('x') are totally different in Sage I
> will be unhappy about
> that. Either the result has to always be in SymPy or always in Sage
> or we have to get
> an error and request that the user explicitly do a coercion.
>
> We have to decide on a canonical map in exactly one direction, and I
> prefer
>
> SymPy ---> SymbolicRing,
>
> just because SymbolicRing is more native in Sage, and probably could be
> improved
> so it would support any SymPy expression (yes -- I know this isn't
> true now, unfortunately).
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.
> Now that I read through #1189 patch, I'm uncomfortable with
>
> return _verify_canonical_coercion_c(x,y)
>
> The function _verify_canonical_coercion_c is supposed to be like
>
> assert(parent(x) is parent(y))
>
> it's *never* supposed to be called when the parents are different -- if it
> is,
> that means there is a bug. However, you're using it to test whether the
> parents are different, and if so do some other behavior (i.e., eventually
> raise
> a TypeError). So that makes me nervous. It would be better to just
> directly do a call to the have_same_parent function, like in the
> implementation
> of _verify_canonical_coercion_c in coerce.pxi.
Agreed.
David
--~--~---------~--~----~------------~-------~--~----~
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/
-~----------~----~----~----~------~----~------~--~---
