Differentiate(x, n) returns raw chain-rule output where Differentiate(x) n times returns the answer

[Rafael-SOWNet]

Measured on master at 5211ccd6. Not about constants — this is an ordinary variable.

var x = MathS.Var("x");
"x ^ 3".ToEntity().Differentiate(x, 2)                     // (0 * x ^ 2 + 2 * x ^ 1 * 1 * 3) * 1 + 0 * 3 * x ^ 2
"x ^ 3".ToEntity().Differentiate(x).Differentiate(x)       // 2 * x * 3

Same value, and one of them is an answer.

Why

The two overloads take different routes:

public Entity Differentiate(Variable variable)
    => Transformation.Differentiation(variable).ApplyOrKeep(this);

internal Entity DifferentiateOnce(Variable variable)
    => InnerDifferentiate(variable).InnerSimplified;      // <- the simplification

public Entity Differentiate(Variable x, int power)
{
    ...
        ent = ent.InnerDifferentiate(x);                  // <- straight to the raw form
    ...
}

Differentiate(Variable) goes through the transformation, which ends at DifferentiateOnce and calls InnerSimplified. Differentiate(Variable, int) calls InnerDifferentiate directly in its loop, so nothing is ever simplified — and because each iteration differentiates the unsimplified result of the last, the expression compounds: every 0 * and * 1 the chain rule produces is still there to be differentiated again on the next pass.

That is also why it is worse than a cosmetic difference. At power = 3 the input to the third differentiation is already the unreduced output of two, so the cost grows with the mess rather than with the derivative.

Not the first-power case

Differentiate(x, 1) is fine — one raw pass is what InnerDifferentiate is for, and there is nothing accumulated yet. It is power >= 2 that diverges, and power = 0 (returns the input) and power < 0 (integrates) are unaffected.

Fix

Use DifferentiateOnce in the loop, which is the method that exists for exactly this and is what the other overload reaches anyway.

Found while measuring #993, where "pi ^ 3".Differentiate(MathS.pi, 2) shows the same shape — but that one is about the constant, and this reproduces with any variable, so it is separate.

[Rafael-SOWNet]

Fixed in #1003 — with two corrections to what I wrote above.

The fix I proposed here breaks the library. "Use DifferentiateOnce in the loop" overflows the stack:

$ probe 'innersimp::derivative(x!, x, 2)'
Stack overflow.
Repeated 3214 times: ...
   at AngouriMath.Entity.DifferentiateOnce(Variable)
   at AngouriMath.Entity.Differentiate(Variable, Int32)
   at AngouriMath.Entity+Derivativef+<>c__DisplayClass20_0.<InnerSimplify>b__0(...)

Derivativef.InnerSimplify decides whether a derivative can be taken by asking for it and keeping the node when a Derivativef comes back — is var res and not Derivativef. That test is the termination condition, and it only works while Differentiate(var, n) is raw. Make it simplify and it simplifies the very node it is deciding about, which asks for the derivative again, without end. The raw loop has to stay; it is now an internal InnerDifferentiate(Variable, int) that only that caller uses, and the public overload is the one that simplifies. It also answers the // TODO: should we call InnerSimplified here? sitting above that arm — no.

And power = 1 is not fine, which I claimed above:

"x ^ 3".ToEntity().Differentiate(x, 1)   // was: 3 * x ^ 2 * 1     now: 3 * x ^ 2

One raw pass still leaks its * 1. What is unaffected is n = 0 and n < 0.

One more thing worth recording, because it is a wrong answer rather than a crash and only the suite caught it: the raw variant must keep the negative-power branch. My first version dropped it on the reasoning that raw differentiation has nothing to do with integration — and a loop that never runs returns its input, which is not a Derivativef, so the caller took it for a resolved answer:

DerivativeToIntegralSimplify   Expected: integral(apply(f, x), x)   Actual: apply(f, x)

Seven cases went into work/crashcheck for this shape, covering both signs of the power.