On Nov 25, 2007, at 8:15 PM, William Stein wrote:
> On Nov 25, 2007 6:33 PM, David Roe <[EMAIL PROTECTED]> wrote:
>> Addition not commuting there bothers me. I can see why it's
>> happening: a
>> SymPy object doesn't call into the coercion system. One possible
>> solution
>> is to have coercion map sage objects into sympy, so both s+o and o
>> +s (in
>> line 134 and 135 of test_sympy.py) would be SymPy objects. Is
>> SymPy and the
>> SymbolicRing canonically isomorphic? Can every SymbolicRing
>> element be cast
>> into SymPy?
>
> 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).
If the canonical map goes this direction, then the __add__ method of
SymPy objects needs to detect sage objects. I.e.
if isinstance(other, SageObject):
return self._sage_() + other
...
However, one cannot assume that SageObject is importable (nor does
one want to try and import it at every step, though this is much
faster than importing sage.all). I'm not sure the cleanest way to do
it. Perhaps there could be a method is_SageObject(x) that, at first
call, tries to import sage.structure.sage_object and on success
returns isinstance(x, SageObject) and on failure returns False. The
result of this import would be cached.
Alternatively, the root SageObject type could have an attribute that
one could look up to test its "sage-ness"
> 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.
>
> In summary, the way the code is written now will work fine now, but
> seems
> a little abusive.
I think the code here should simply be
330 if PY_TYPE_CHECK(xp, type) or PY_TYPE_CHECK(yp,
type):
331 if hasattr(x, "_sage_") and hasattr(y, "_sage_"):
332 return canonical_coercion_c(x._sage_
(),y._sage_())
--~--~---------~--~----~------------~-------~--~----~
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/
-~----------~----~----~----~------~----~------~--~---
