#20185: Upgrade to SymPy-1.0
-------------------------------------+-------------------------------------
Reporter: rws | Owner:
Type: enhancement | Status: needs_review
Priority: major | Milestone: sage-7.1
Component: packages: | Resolution:
standard | Merged in:
Keywords: | Reviewers:
Authors: Ralf Stephan | Work issues:
Report Upstream: N/A | Commit:
Branch: | 76a47e825dfc3e2cc0d56244ababdc9fb92d5481
u/rws/upgrade_to_sympy_1_0 | Stopgaps:
Dependencies: |
-------------------------------------+-------------------------------------
Comment (by tscrim):
Okay, I think I have a better understanding of things. So here's what I
think is going on. The coercion system is working fine:
{{{
sage: import sympy
sage: u = sympy.Function('u'); n = sympy.Symbol('n', integer=True)
sage: import operator
sage: cm = sage.structure.element.get_coercion_model()
sage: cm.common_parent(3, u(n))
Symbolic Ring
sage: cm.common_parent(u(n), 3)
Symbolic Ring
sage: type(cm.bin_op(3, u(n), operator.mul))
<type 'sage.symbolic.expression.Expression'>
sage: type(cm.bin_op(u(n), 3, operator.mul))
<type 'sage.symbolic.expression.Expression'>
}}}
That is now returning something rather than erroring out. This is coming
from
{{{
sage: (u(n))._sage_()
u(n)
sage: type(_)
<type 'sage.symbolic.expression.Expression'>
}}}
We go to the coercion framework because of `__mul__` from integers.
Previously, because it was erroring out, the multiplication code then
tried `__rmul__` from the !SymPy function, which resulted in a !SymPy
object. Now, we get different behaviors because when the !SymPy object is
on the left, we call its `__mul__`, which results in a !SymPy object.
I'm also retracting the last part of comment:15, and the issue might be in
!SymPy and how it tries to parse our symbolic expressions:
{{{
sage: f = function('f')
sage: x = var('x')
sage: sympy.sympify(f(x), evaluate=False)
f(x)
sage: sympy.sympify(3*f(x), evaluate=False)
AttributeError: 'Call' object has no attribute 'id'
}}}
However, we do seem to have our own troubles of constructing !SymPy
objects from symbolic expressions. All of these result in errors:
{{{
sage: f._sympy_()
sage: f(x)._sympy_()
sage: (f(x)+3)._sympy_()
}}}
I'm okay with your patch. Although we typically set the first patched
version to `p0`.
--
Ticket URL: <http://trac.sagemath.org/ticket/20185#comment:23>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/sage-trac.
For more options, visit https://groups.google.com/d/optout.
