Register every rule set the simplifier applies, and route it through them

[Rafael-SOWNet]

Stacked on #816 — merge that first. Prerequisite for #28.

Why this comes before #28, not after

The registry held ten rule sets. Simplificator applies twenty-two, reaching most of them through Patterns directly. A set reachable only by its method has no name to report and nothing to attribute a step to, so a step recorder wired to the registry today would produce a derivation of Simplify that silently omitted most of what actually fired. That is a plausible-looking answer that is not the truth, which this repo ranks below no answer at all — so the sweep has to land first.

What changed

All twenty-two are registered, and Simplificator reaches all of them through RewriteRules. Entity.Expand is routed too, so it is not the one catalogue transformation still naming its own rules. Thirty entries in total.

Two sets are parameterised by sort level. Each is registered once per level with an internal chooser beside it (CanonicalOrderAt, CommonDenominatorAt) — the alternative is a registry entry that cannot be enumerated, which defeats the point of All.

expression.Rewrite(ruleSet) is an internal extension over RewriteRuleSet.ApplyOnce, so a sequence of a dozen rule sets still reads in the order it runs instead of inside out.

This is a rename at every call site. ApplyOnce is Replace(rules); nothing about the order, the guards or the candidate selection moved.

Measurements

Against d1c4a4dd (the parent), net10.0/Release, two samples each. Allocation is deterministic and reproduced exactly across both runs:

	parent	this branch
SimplifyEasy	157.6 KB	125.8 KB (−20%)
SimplifyCommon	6971.1 KB	6867.8 KB
Limit	7658.0 KB	7516.4 KB
Integrate	1774.5 KB	1759.5 KB
ParseEasy / Differentiate / Expand / Factorize / SolveEasy	unchanged	unchanged

Not noise, and it has a cause: Patterns.SortRules(level) returns a fresh closure on every call, and so does the common-denominator lambda. Both ran once per pass inside the simplification loop; they are now cached registry entries. Timings are unchanged within run-to-run variance.

Tests

5773 passing, 0 failed, 15 skipped (up from 5707/14 — the extra skip is #817's). F# 130 passing.

The tests over RewriteRules.All now cover thirty sets rather than ten, and the corpus gained boolean, comparison, set, factorial and totient expressions so those sets are actually exercised rather than passed over on inputs they cannot match. Every registered set still reaches a fixed point within 32 passes, and every one is deterministic.

Two things the widened corpus turned up

A pre-existing crash, filed as #817. "(x + 1)! / x!".Expand() throws AngouriBugException — a public method reporting that the library is broken, on an expression Simplify answers as 1 + x. It reproduces on d1c4a4dd, where Expand's logic is untouched by either PR, so it is not from this work. A skipped regression test is included here referencing the issue; the fix belongs in its own change.

The equivalence property test was wrong twice over. Both are fixed, and both are worth naming because each would have produced a confident false report:

• Sets subtract elementwise, so the difference of two equal sets is the set of pairwise differences, not zero. { 1, 2 } unite { 2, 3 } duly "failed". Set-valued results are now compared by simplifying both sides.
• Simplifying a difference to zero proves the two agree; failing to does not prove they differ. x! * (x + 1) expands to (x + 1)! — correct — and the difference does not reduce. The test now looks for an actual counterexample at sample points before calling anything a defect, with a relative tolerance and with points where either side is undefined or infinite passed over rather than counted against a rewrite that is only valid away from a pole.

The counterexample search has its own test, because a property check that silently catches nothing is worse than none: it must separate x + 1 from x + 2, x ^ 2 from x ^ 3 and sqrt(x) from -sqrt(x), and must not separate x * 2 from 2 * x, x! * (x + 1) from (x + 1)!, or sqrt(12) + sqrt(27) from 5 * sqrt(3).

What still bypasses the registry

The equation and set solvers, the integrator and TreeAnalyzer still call Patterns directly. That is outside "what the simplifier did" and can follow separately. Patterns.TrigonometricToExponentialRules(from, to) cannot become an entry as it stands — parameterised by two variables, it is a family of sets rather than one.

🤖 Generated with Claude Code