On Nov 26, 2007 7:36 PM, Robert Bradshaw <[EMAIL PROTECTED]> wrote:
>
>
> 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_())
That was my original patch, as seen here:
http://sagetrac.org/sage_trac/attachment/ticket/1189/sympy.patch
and it doesn't work, because sometimes SAGE puts "x=5" and
"y=something else" in, and expects to receive a TypeError, otherwise
it segfaults.
That's why the workaround.
Ondrej
--~--~---------~--~----~------------~-------~--~----~
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/
-~----------~----~----~----~------~----~------~--~---
