About the arithmetic refactor

[mmatera]

Motivation

When I started with #766, I have the following goals:

1. Improve the compatibility with WMA in the way arithmetic expressions are handled.
2. Make the implementation of these builtins functions easier to understand, in a way that finds performance bottlenecks, or even understands why some evaluations pass or fail tests after unrelated changes be easier.
3. make the interactions between mathics-core and Sympy clearer, and eventually allows to decouple of mathics-core from the Sympy dependency, while having a very basic arithmetic functionality.

My first reason to do 1. was to make it easier to compare test cases against WMA, as well as do some inverse engineering to determine where are our bottlenecks in performing evaluations. Also, arithmetic involves some of the main issues related to formatting, so reinforcing compatibility at this point would help also to guide how to improve our formatting system. On the other hand, a third reason would be to provide compatibility with existing WL code that relies on the canonical form associated with arithmetic expressions.

The reasons for 2. were discussed many times before, so I think I do not need to stay too much on this point. Arithmetic expressions are basic elements of a programming language and deserve to have the clearest implementation possible.

The reason for 3., related to the previous ones, is that if Mathics uses Sympy for many evaluations, it is not just a translation wrapper of this library. If it were a wrapper, arithmetic evaluation could be implemented just like

    def eval_Plus(self, *elements, evaluation):
        return from_sympy(Add(*[e.to_sympy() for e in elements])) 

However, if we do that, we break hundreds of tests. The reason is that Sympy has a different internal logic than WL, and that the canonical forms Sympy assumes are different from the WL. Then, thinks as the order of the terms in an addition, or when to factorize, or rationalize numbers are different. In typical cases, the work of canonicalizing the output of a Sympy evaluation is more or less the same that doing the evaluation without using Sympy. Moreover, as the conversions are done back and forth many times in the Mathics evaluation loop, the overhead is worst. The impact of this last part could be reduced by implementing some kind of caching, but with the current implementation of from_sympy/to_sympy such caching can not be implemented using standard functools.lru_cache

[rocky]

I am in favor of the goals although I think some are more involved and the details are slightly different.

The way accomplishing the broad idea has been gone about and its current implementation I am concerned with.