Merge two powers of one base in a product (#781), and guard a zero integration rate (#785)

[Rafael-SOWNet]

Fixes #781 and #785.

An integrand that is a power in disguise was declined. x ^ 2 / x came back as an unresolved integral, and sin(x) ^ 4 * (-6) * sin(x) ^ 2 was not answered at all -- both elementary, and both answered the moment the same expression is written with the powers already merged.

Two things kept the powers apart

Patterns.PowerRules has the rule, but it pairs two sibling nodes, and a product is a tree rather than a list:

Mulf(Mulf(Powf(sin(x), 4), -6), Powf(sin(x), 2))

The constant sits between the two powers, so they are never siblings and the rule never fires. Separately, Integrate normalises with InnerSimplified, which does not run PowerRules at all -- which is why even x ^ 2 / x, where the two powers are siblings, was missed.

Full Simplify gets these because it reassociates and sorts the factors first. That explains the shape the issue reported: every argument other than a bare x already answered, because those go through a substitution that happens to rebuild the tree on its way past. The merge was only ever reached by accident.

What this does

Gathering walks the flattened factors and keys them by base, so it reaches through any number of intervening factors rather than one.

a^n * a^m = a^(n+m) needs no condition: with a^n read as e^(n Log a) on the principal branch, the two sides are e^(n Log a) * e^(m Log a) and e^((n+m) Log a), equal for every complex n and m. That is what makes it unlike (a^b)^c = a^(b*c), which moves the branch and is guarded (#752).

Two things it must not do, both found by measurement rather than by reading:

• Only the exponents it builds are folded, never the product around them. InnerSimplified on the whole expression rewrites x^(-2) back into 1/x^2, and SolveAsPolynomialTerm rewrites a 1/x^n it is handed into Pow(x, -n). The two normalisations chase each other until the stack runs out -- this aborted the test run before it was found.
• It rebuilds only when a merge actually happened, since flattening writes every quotient as a negative power and rebuilding unconditionally would rewrite every quotient in the tree.

The second commit is a defect this reaches (#785)

Gathering e^x * e^(-x) produces e^(x + -x), whose linear rate is zero while x + -x is still written out. Every rule in the standard-integral table divides by that rate unguarded, so the answer came back with a literal division by zero in it:

"e ^ (x + -x)".ToEntity().Integrate("x")   // e ^ (x + -x) / (0 * ln(e))  -- NaN, it is x

This is on master already -- writing the exponent out reaches it without any of the above -- but this PR makes it reachable from ordinary input, and without the guard sinh(x)^2 - cosh(x)^2 answers NaN where master answers correctly. So it is fixed here rather than left to be found later.

Each of those integrands depends on x only through the argument whose rate is read, so a zero rate means the integrand is a constant and integrates to itself times x. One guard ahead of the table answers the family. The rate has to be decidably zero -- a symbolic one is not, and answering sin(a * x) * x would be wrong for every non-zero a.

Measured

integrand	before	after
x ^ 2 / x	declined	x ^ 2 / 2
x ^ 2 * (1 / x)	declined	x ^ 2 / 2
x ^ 3 / x ^ 2	declined	x ^ 2 / 2
sin(x) ^ 4 * (-6) * sin(x) ^ 2	declined	answered
e ^ (x + -x)	NaN	x
sin(x + -x)	NaN	0
x ^ 2 * x	answered	unchanged
sin(2 * x) ^ 4 * (-6) * sin(2 * x) ^ 2	answered	unchanged
e ^ (2 * x), sin(3 * x + 1)	answered	unchanged

Harnesses, against master (e05d7179):

• unit tests 5418 pass, 0 fail; F# 130/130
• casbench 113/117, 0 wrong / 0 error / 0 timeout -- unchanged
• rootcheck 596/596 clean; simpsweep 10463/10463 agree
• propcheck 1337 -> 1340 checks, 0 failures either side: three more integrals answer, all of them correct

Performance, on the Tests.Calculus subset (two runs each): master 860 tests in 56 s and 57 s; this branch 880 tests in 55 s and 55 s. The gathering is a tree walk on every recursive integrate call and does not show up.

Notes for review

• LinearityBeforeByPartsTest.PowersOfOneBaseAreNotMerged in Distribute over a sum before searching by parts (#779) #782 pins the old behaviour deliberately and will need removing when both land. This branch is cut from master and does not contain it.
• The abs case of A zero linear rate is divided by, so Integrate answers NaN for an argument that mentions x without depending on it #785 is checked on the antiderivative rather than by differentiating it back: the library differentiates abs(u) as sgn(u) * u' and answers NaN at u = 0, so the round trip says nothing either way. That is a separate quirk and is not touched here.

🤖 Generated with Claude Code