Add sum and product, the first operators that bind a variable over a range (#248)

[Rafael-SOWNet]

Closes #248 for Σ and Π. The n-ary set operators (⋃, ⋂) are not included — see below.

sum(k, k, 1, 10)        55
product(k, k, 1, 5)     120
sum(k^2, k, 1, 4)       30
sum(k, k, 1, n)         sum(k, k, 1, n)      — carried, not refused
sum(x, k, 1, 3)         3 * x
sum(k, k, 5, 1)         0                    — empty sum
product(k, k, 5, 1)     1                    — empty product

Nodes, not a parser trick

The bounds may be symbolic, and sum(k, k, 1, n) is a well-formed expression with no finite expansion. A parser-level version that only worked for concrete bounds would have to change shape later, so this is Summationf and Productf as CalculusOperators alongside Integralf and Limitf.

Where the bounds are concrete integers and there are at most 100 terms it expands; otherwise it is carried. A thousand-term expansion is correct and useless, and everything downstream then walks it.

The empty range returns the operator's identity explicitly — 0 for a sum, 1 for a product — rather than letting the accumulator's initial value fall out of the loop, where it would read as a coincidence rather than a decision.

The index is bound

This is the part that is easy to get wrong, and #878 is it going wrong for set-builders. Substitute alpha-renames before substituting, exactly as Integralf does:

"sum(k, k, 1, n)".ToEntity().Substitute("k", 5)   // unchanged — k is the index
"sum(k, k, 1, n)".ToEntity().Substitute("n", 3)   // 6 — n is free

Both are pinned by tests.

Consistent with the binders already here, rather than inventing conventions

I checked each against integral, lambda, apply and ConditionalSet before choosing:

	sum/product	matches
Vars exposes the index	yes	integral(y, x) → y,x; lambda(x, x^2) → x
solving for an un-invertible binder	{ }	apply(f, x) → { }
differentiating / limiting one	unevaluated operator	#958's lesson — not NaN
DomainCondition	True	Integralf

One of those is worth flagging rather than hiding. sum(k, k, 1, n) = 0 solved for n answers { }, and n = 0 is a solution (the empty sum is 0). That is the existing convention for a binder the solver cannot invert — apply(f, x) does the same — so I matched it rather than deviating in one new node. If that convention is wrong it is wrong in three places and should be changed in all of them; #964 is the same family.

i is the imaginary unit

sum(i, i, 1, 10) is left unevaluated, because i is not a Variable and so binds nothing. Every textbook writes this sum with i, so it is documented on the parameter and pinned by a test. It declines rather than guessing.

Evidence

• suite 7297 passed, 0 failed; 17 new tests
• PublicApi.txt regenerated
• the parser was regenerated from the grammar with the vendored ANTLR jar and the post-processor, so the committed parser matches AngouriMath.g — Fail CI when the committed parser no longer matches its grammar (#898) #965 adds a CI check for exactly that
• LaTeX (\sum_{k=1}^{n}, \prod_{k=1}^{n}), Stringize round-trip, and sympy.Sum/sympy.Product export are all covered

Not included

⋃ and ⋂, the other two operators the issue names. They bind over a family of sets rather than a numeric range, and the set layer has its own union/intersection already; that is a separate design question and I would rather it were decided than assumed.

This also does not add => or juxtaposition syntax (#495) or quantifiers (#225) — but it establishes the pattern both would follow, which is what makes them cheaper now.

🤖 Generated with Claude Code

[Happypig375]

It might be desirable to allow redefining how i parses in the sum if it's declared as the loop variable.

Also, refer to WolframAlpha and Sympy if the expression should be at front or end; we write the iteration index and limit in the front in math.