Revision history [back]

In this case, the problematic translation is the one for "atan".

There are lots of cases tike this for translations from Fricas, Maple and Mathematica, especially for special functions such as hypergeometric or Fresnel.

Other problematic cases exist for more convoluted cases. For example, Sympy's case has semantics more general than Sage's cases, and some variants can't (yet) be handled.

Some fallback mechanisms exost, for example, in Mathematica's case, where one can add a list of "additional" translations. But even this is insuficient : for example, the Mathematica -> operator is polysemic, in a Sage-unfriendly way. I've started to think about a (semi-)general way of handling this, but I'm not tyet at an acceptable solution.

A shameful workaround in a paper is to ask the target interpreter to create a LaTeX representation of the result, use that to print in the paper, and to manually translate in Sage for the rest of the computations. It's ugly but allows you to progress... This, for example, allows to handle the "general" case of Sympy's case.

In this case, the problematic translation is the one for "atan".

There are lots of cases tike this for translations from Fricas, Maple and Mathematica, especially for special functions such as hypergeometric or Fresnel.

Other problematic cases exist for more convoluted cases. For example, Sympy's casePiexewise has semantics more general than different from Sage's cases, and some variants can't (yet) be handled.

Some fallback mechanisms exost, exist, for example, in Mathematica's case, where one can add a list of "additional" translations. But even this is insuficient : for example, the Mathematica -> operator is polysemic, in a Sage-unfriendly way. I've started to think about a (semi-)general way of handling this, but I'm not tyet yet at an acceptable solution.

A shameful workaround in a paper is to ask the target interpreter to create a LaTeX representation of the result, use that to print in the paper, and to manually translate in Sage for the rest of the computations. It's ugly but allows you to progress... This, for example, allows to handle the "general" case of Sympy's casePiecewise.

In this case, the problematic translation is the one for "atan".

There are lots of cases tike this for translations from Fricas, Maple and Mathematica, especially for special functions such as hypergeometric or Fresnel.

Other problematic cases exist for more convoluted cases. For example, Sympy's PiexewisePiecewise has semantics different from Sage's cases, and some variants can't (yet) be handled.

Some fallback mechanisms exist, for example, in Mathematica's case, where one can add a list of "additional" translations. But even this is insuficient : for example, the Mathematica -> operator is polysemic, in a Sage-unfriendly way. I've started to think about a (semi-)general way of handling this, but I'm not yet at an acceptable solution.

A shameful workaround in a paper is to ask the target interpreter to create a LaTeX representation of the result, use that to print in the paper, and to manually translate in Sage for the rest of the computations. It's ugly but allows you to progress... This, for example, allows to handle the "general" case of Sympy's Piecewise.