Count a division by what it is, not by how it was written (#950)

[Rafael-SOWNet]

Closes #950.

FewestDivisions tested the exponent's node — Powf(_, Real { IsNegative: true }) — so in y ^ (1 * (-1)) * x, where the exponent is a Mulf, it fired on nothing:

expression	FewestDivisions was	is
x / y	1.003	1.003
y ^ (-1) * x	1.005	1.005
y ^ (1 * (-1)) * x	0.007	1.007

All three are one value written three ways. The model rated the writing whose division it could not see as the cheapest of the three — under the criterion whose whole job is removing divisions. FewestRadicals had the same shape of test and the same blind spot, so x ^ (2 ^ (-1)) was not a square root to it.

Both now ask what the exponent evaluates to. One division each, and the smallest tree wins, which is what the node term exists to settle.

Why this and not the other two options

The issue listed three, and I originally leaned to documenting the precondition and leaving the models alone. The argument against that is a split the issue did not name:

• SmallestTree and Default count spelling. y ^ (1 * (-1)) * x really is a bigger tree. Reading the node as written is not an approximation of their question, it is their question. Evaluating inside Cost (option 1) would therefore make these two wrong, not just slower.
• FewestDivisions and FewestRadicals count a mathematical feature. "Is there a division here" is a property of the value. For these, reading the written node is simply the wrong question.

So the fix is per-model rather than global, and documentation alone would have left a built-in model preferring a hidden division. "A caller could write a wrong model too" argues for explaining the distinction — which this does, in the type's remarks — not for leaving a shipped model wrong.

Default and SmallestTree are untouched, and there is a test pinning that.

Behaviour

Simplify's output does not change. Measured rather than reasoned: twelve division-heavy inputs under both models, on a build of each side, twenty-four results, byte-identical. Simplify scores candidates it has already evaluated, so it never reached the gap.

What reaches it is a caller scoring expressions it did not build — extraction on an e-graph, where every writing of a value is a member of one e-class at once, which is how this was found. That is exactly the use CostModel (#949, #746 item 52) exists to enable, which is why this is worth fixing rather than documenting.

Recorded in BREAKING-CHANGES.md: Cost returns different numbers for an expression with an unevaluated exponent.

Evidence

• suite 7257 passed, 0 failed, 14 skipped
• 2 of the 3 new tests fail without the source change. The third passes either way by design — it pins that SmallestTree still counts spelling, so it is a guard against overreach rather than evidence for the fix, and it should not be read as a third supporting test.

What it does not do

• Does not change Default or SmallestTree, or the default Simplify path.
• Does not evaluate inside Cost generally — a caller's own model still reads what it is given, and the remarks now say so and explain which of the two kinds it should be.
• Does not touch Feature's node-term weighting.

🤖 Generated with Claude Code