[tombouctou]

Sum and Product with integer bounds now add (or multiply) the terms directly. SymPy is used only when the bounds are not integers.

Before this change, IterationFunction.eval_iter sent every Sum/Product with step 1 through SymPy. The summand was converted to SymPy, the terms were evaluated by Mathics3, the result was converted to SymPy again, put through Together, converted back to Mathics3 and then put through Cancel. With integer bounds, all that is needed is to evaluate the terms and add them, as Table does. When the terms are large symbolic expressions, the round trip costs far more than the sum itself.

In[1]:= Sum[1/(x + i), {i, 1, 2}]
master:  (3 + 2 x) / ((1 + x) (2 + x))
branch:  1 / (1 + x) + 1 / (2 + x)

The new form is, as far as I can tell, also what WMA returns: it does not put an explicit finite sum over a common denominator. Symbolic bounds (Sum[i, {i, 1, n}]) and infinite sums go through SymPy as before.

Tests: test_sum_product_bounds in test/builtin/test_arithmetic.py. The full pytest suite and doctests pass.

Context: we found this while profiling the lambda-algebra homology computation from the Toda-bracket project we are running on Mathics3 (see #2001). In that workload, SymPy conversion inside Sum took about 40% of the profile on small cases. Adding the terms is itself costly, though, so on the same core the end-to-end gain is a few percent.

🤖 Generated with Claude Code

[mmatera]

LGTM

[rocky]

Thanks for profiling and fixing this!