[ Long story: see this ask.sagemath.org question
<https://ask.sagemath.org/question/46419/a-goat-in-a-tether/>, which
already generated Trac#27816 <https://trac.sagemath.org/ticket/27816> ].
Consider :
x,y,r0,r1,t=var("x,y,r0,r1,t", domain="real")
assume(r0>0, r1>0, r1<=2*r0)
E0=x^2+y^2==r0^2
E1=(r0-x)^2+y^2==r1^2
with assuming(y>0): foo=E0.solve(y, solution_dict=True)[0].get(y)
Y0(x)=foo
with assuming(y>0): foo=E1.solve(y, solution_dict=True)[0].get(y)
Y1(x)=foo
X=(Y0(x)^2==Y1(x)^2).solve(x, solution_dict=True)[0].get(x)
This works uneventfully. The problem begins with:
sage: foo=integrate(2*Y1(t), t, r0-r1, X, algorithm="giac")
sage: foo.subs([r0==10,r1==10])
100/3*pi*sign(10) - 25*sqrt(3)
sage: foo.subs([r0==10,r1==10]).n()
---------------------------------------------------------------------------
TypeError Traceback (most recent call last)
<ipython-input-99-18e285680886> in <module>()
----> 1 foo.subs([r0==Integer(10),r1==Integer(10)]).n()
/usr/local/sage-8/local/lib/python2.7/site-packages/sage/structure/element.pyx
in sage.structure.element.Element.n
(build/cythonized/sage/structure/element.c:8009)()
859 0.666666666666667
860 """
--> 861 return self.numerical_approx(prec, digits, algorithm)
862
863 def _mpmath_(self, prec=53, rounding=None):
/usr/local/sage-8/local/lib/python2.7/site-packages/sage/symbolic/expression.pyx
in sage.symbolic.expression.Expression.numerical_approx
(build/cythonized/sage/symbolic/expression.cpp:33967)()
5949 res = x.pyobject()
5950 else:
-> 5951 raise TypeError("cannot evaluate symbolic expression
numerically")
5952
5953 # Important -- the we get might not be a valid output for
numerical_approx in
TypeError: cannot evaluate symbolic expression numerically
Huh ?
Working my way through the expression, I come up with :
sage: foo.operands()[0].operands()
[pi, r1^2, sign(r1), 1/2]
sage: foo.operands()[0].operands()[2].operator()
sign
sage: foo.operands()[0].operands()[2].operator().parent()
<class 'sage.symbolic.function_factory.NewSymbolicFunction'>
sage: sign.parent()
<class 'sage.functions.generalized.FunctionSignum'>
And, by the way :
sage: sign(r1).subs(r1==10)
1
It seems that the back-conversion from giac to age was unable to fing
Sage's signe, and created a new symbolic function with the exact same name.
This seems awfully close to the already fixed (but recent) Trac#27577
<https://trac.sagemath.org/ticket/27577>.
By the way, the problem might cause serious and permanent problems :
sage: SR(str(foo.operands()[0].subs(r1=10))).n()
---------------------------------------------------------------------------
TypeError Traceback (most recent call last)
<ipython-input-125-d87f5d95bbf0> in <module>()
----> 1 SR(str(foo.operands()[Integer(0)].subs(r1=Integer(10)))).n()
/usr/local/sage-8/local/lib/python2.7/site-packages/sage/structure/element.pyx
in sage.structure.element.Element.n
(build/cythonized/sage/structure/element.c:8009)()
859 0.666666666666667
860 """
--> 861 return self.numerical_approx(prec, digits, algorithm)
862
863 def _mpmath_(self, prec=53, rounding=None):
/usr/local/sage-8/local/lib/python2.7/site-packages/sage/symbolic/expression.pyx
in sage.symbolic.expression.Expression.numerical_approx
(build/cythonized/sage/symbolic/expression.cpp:33967)()
5949 res = x.pyobject()
5950 else:
-> 5951 raise TypeError("cannot evaluate symbolic expression
numerically")
5952
5953 # Important -- the we get might not be a valid output for
numerical_approx in
TypeError: cannot evaluate symbolic expression numerically
I can, of course, open a ticket for this and fix it, but I begin to wonder
if it would not be beneficial to revise all (symbolic) functions for
convertibility to other symbolic systems. In fact, I have another example
on hand :
sage: mathematica.D(arctan(x),x)
Derivative[1][Arctan][x]
sage: mathematica("D[ArcTan[x],x]")
(1 + x^2)^(-1)
So a systematic revision might be better than a raft of isolated tickets.
This might also be used to treat the case of different expressions in
different systems of the tsame mathematuic being. Case in point :
Mathematica has a few special cases for hypergeometric functions added to
the generic case, whereas Sage has only one generic function ; creating the
special-case functions would allow back-conversion to Sage of Mathematica
results using them.
Advice ? Hints ?
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sage-devel/e8ead156-0657-4ab8-a6c9-00d605c5a618%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
