Recognise repeated and joined contractions when sum factorising

[pbrubeck]

Fixes #283 by recasting sum-factorization as a DP tree traversal with cost growing
with the number of factors as opposed to contraction indices, and falling back to
the original index combinatorial search when there are too many factors.

TLDR: #280 kept an already factorised contraction whole by asking the caller to
pass stop_at. This PR drops that second pass and gets the same result from the
expression itself, by not flattening a contraction that is used more than once
and by planning the product tree instead of searching orderings of the indices.

What changes

• Flattening a contraction renames its indices apart. That is what makes it
  sound, but it also means a coefficient evaluation used three times becomes
  three independent contractions, and is computed three times. So don't flatten
  a contraction that occurs more than once in the product. Expanding a product
  only pays where factorising the expanded form recovers the sharing that
  expansion broke, which multilinearity guarantees; a product of repeated
  evaluations is not multilinear in them, so there is nothing to recover.

• Plan the product tree, not the index ordering. Searching orderings has to
  multiply every factor carrying an index before it can reduce that index, so it
  can never reduce over part of a product and multiply the rest in afterwards.
  Build the tree by dynamic programming over subsets of the factors, reducing
  each index at the smallest subtree that holds every factor carrying it. That
  costs 3^factors rather than indices!, and plans the contractions that a
  tensor value index joins together.

• With the tree planned, dual evaluation no longer needs the inner
  sum_factorise, so only one gem.optimise.contraction remains, and the bound
  on the ordering search stays where it was.

• Recognising a repeated contraction from the expression retires the stop_at
  argument of contraction and the is_contraction predicate Keep factorised contractions atomic in dual evaluation #280 added for it,
  which nothing passes any more. traverse_product and traverse_sum keep their
  own stop_at, which gem.refactorise still uses.

Interpolation on a hexahedron

Kernel flop counts and temporaries, as count / entries / largest.

interpolate	flops main	flops PR	temporaries main	temporaries PR	compile main	compile PR
f*f*f, CG1 → CG1	96	96	9 / 11 / 2	9 / 13 / 2	0.011 s	0.011 s
f*f*f*f, CG1 → CG1	104	104	9 / 11 / 2	9 / 13 / 2	0.011 s	0.011 s
f*f, CG4 → DG3	2568	2568	4 / 51 / 25	4 / 66 / 25	0.008 s	0.009 s
dot(u, u)*u, vector CG4 → vector CG4	23875	23875	14 / 210 / 75	14 / 270 / 75	0.017 s	0.018 s
dot(A, A), tensor CG2 → tensor CG3	16776	16776	81 / 240 / 4	81 / 240 / 4	0.089 s	0.163 s
inner(A, A), tensor CG2 → CG2	4131	4131	120 / 126 / 3	120 / 180 / 3	0.126 s	0.129 s
grad(f)[0], CG4 → CG4	14106	13981	92 / 292 / 25	91 / 375 / 25	0.066 s	0.066 s
div(u), vector CG4 → DG3	23548	23100	110 / 391 / 25	109 / 543 / 25	0.080 s	0.077 s

Every case that raised NotImplementedError: Too many indices for sum factorisation! on the base of #280 still compiles here.

dot(A, A) costs 0.078 s more to compile. It is the one case here whose value
index joins the evaluations into a contraction of seven indices, so it is the
one case that reaches the planner with enough factors to plan.

Helmholtz on an extruded hexahedral mesh

inner(u, v)*dx + inner(d(u), d(v))*dx, with d = grad for CG and curl for
NCE. This is the cost of the planner where nothing needed fixing.

	flops main	flops PR	entries main	entries PR	compile main	compile PR
CG1	14732	14732	1153	1171	0.120 s	0.126 s
CG3	611668	611668	4460	4502	0.105 s	0.103 s
CG7	37651332	37651332	90392	90482	0.101 s	0.104 s
NCE1	136618	136651	7151	7178	1.028 s	1.003 s
NCE3	4486030	4486063	22058	22109	0.754 s	0.758 s
NCE7	282933862	282933895	612438	612537	0.752 s	0.755 s

Compile time here is within run to run variation either way. The NCE forms cost
33 flops more at every degree. The planner finds cheaper
trees for three subproblems of those forms, 70 against 90 operations each, but costs
each connected subproblem on its own while the subproblems share terms, so the
cheaper trees drop a shared subexpression. Keeping the whole expression in view
when costing a plan is left for later.

Tests

test_sum_factorise.py covers the bound, now on the ordering search the planner
falls back on; an unrestricted contraction keeping a repeated evaluation whole;
and a contraction joined by a value index into more indices than an ordering
search can take. Each was checked to fail when the change it covers is reverted.

AI declaration: written with Claude Code (Claude Opus 5).

[pbrubeck]

This is the algorithmic realisation of splitting sum-factorization into subsets of factors. This models the splitting in dual_evaluation.

Before, we were tackling all indices at once and searching over all possible permutations = indices!.

Now we traverse a tree, by appending factors one by one. The cost is reduced to 3^factors.

[pbrubeck]

Suggested change

evaluation = gem.optimise.contraction(evaluation)

[pbrubeck]

Suggested change

evaluation = gem.optimise.contraction(evaluation)