Conversions to/from other symbolics packages

[Emmanuel Charpentier]

[ Long story: see this ask.sagemath.org question, which already generated Trac#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.

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 ?

[Nils Bruin]

On Monday, May 13, 2019 at 7:46:26 AM UTC-7, Emmanuel Charpentier wrote:

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 ?

What do you mean by "systematic"? It seems to me that you'll basically be checking if a translation dictionary is complete,  correct, and consistent (with the dictionary in the opposite direction). The consistency test lends itself to automation, but the completeness and correctness just requires a human to know/read the language specs and check the dictionary that sage uses.

It could be that the dictionary only exists in distributed form for the sage-to-other_system translation (as attributes on objects), but the translation from other_system to sage must exist as an actual lookup table. So perhaps start with reading that and use it to look up the objects that store the sage-to-other_system translations.