Overflow in computation with large integers

[oscarbenjamin]

This example is from the mathematica docs:
https://reference.wolfram.com/language/tutorial/DiophantineReduce.html

This calculation produces a large integer and then numerical evaluation overflows somehow:

In[1]:= poly = x^100000 + 1234 x^77777 - 2121 x^12345 + 7890 x^999 - x^11
Out[1]:= -x ^ 11 + 7890 x ^ 999 - 2121 x ^ 12345 + 1234 x ^ 77777 + x ^ 100000

In[2]:= freeterm = poly /. x -> 1234567;
Out[2]:= None

In[3]:= N[freeterm]
General::ovfl: Overflow occurred in computation.

Also displaying freeterm is very slow.

By contrast with SymPy (not sure if SymPy is actually involved here):

In [1]: poly = x**100000 + 1234* x**77777 - 2121* x**12345 + 7890* x**999 - x**11

In [2]: freeterm = poly.subs(x, 1234567)

In [3]: N(freeterm)
Out[3]: 2.92690499812734e+609151

[rocky]

If you set $TraceEvaluation = True you will the steps that Mathics is taking and get some sense of why it is slow.

The variable "poly" is stored symbolically as a Mathics Expression, but freeterm isn't - all of those calculations in large precision are being done which is why freeterm is slow. Of course change the = (Set) to := (SetDelayed) and then the evaluation isn't done when assigning freeterm. But when you go to evaluate all of this with N, all of the expansion is done inside Mathics using calls I think to sympy.

[mmatera]

Actually, the evaluation is "fast":

what is very slow in Mathics is to show the 609152 digits of the number. WMA does it pretty fast, while the experiment in Sympy converts it to a floating point number.

In Mathics, this last conversion produces the overflow, because the number is too large to be converted to a MachineReal number. I think this part is easy to fix (see PR #106).

[rocky]

See also #111 (comment)