`integral` lost its three-argument form in 1.4.0, undocumented, and now disagrees with `derivative`

[Rafael-SOWNet]

Found by running the samples in #846 rather than only building them.

Measured

integral accepted three arguments in 1.3.0 and has thrown since 1.4.0. derivative still accepts three. Each row is the published package, parsed in its own process:

version	integral(sqrt(x)/a, x, 1)	derivative(sqrt(x)/a, x, 1)
1.3.0	accepted, reads as integral(sqrt(x)/a, x)	accepted
1.4.0	FunctionArgumentCountException	accepted
2.0.0-preview.1	FunctionArgumentCountException	accepted

integral should have exactly 4 arguments or 2 arguments but 3 arguments are provided

So this is a 1.4.0 change, not a 2.0 one, and it is in the current released version today.

Two things follow

It went out undocumented. BREAKING-CHANGES.md begins at "2.0.0 (unreleased) — since 1.4.0", so a break introduced by 1.4.0 has no home in it. Anyone who upgraded 1.3.0 → 1.4.0 with a three-argument integral in a parsed string got an exception with nothing to point them at. That is worth a line somewhere even now, since 1.4.0 is what dotnet add package still installs.

integral and derivative now disagree. They are the same shape of operation and read the same way:

derivative(f, x, 2)   // second derivative      -- accepted
integral(f, x, 2)     // second antiderivative  -- throws

The likely reason is that integral grew the definite form integral(f, x, from, to), and 2-or-4 was chosen to keep the grammar unambiguous — three arguments sits between them. That is a defensible reason for the restriction; it is not a reason for the two functions to differ, and nothing says so anywhere a caller would look.

Why it stayed invisible for seven months

SampleNet5 and FSharpSample both call integral(f, x, 1). They were pinned to AngouriMath 1.3.0, so they kept compiling and running against a version that still accepted it. Nothing in CI builds or runs the samples. #846 moves them onto ProjectReference, which is what surfaced this.

No unit test covers a three-argument integral either, in any direction — neither that it works nor that it throws. The change has no test recording that it was intended.

What to decide

1. Restore three-argument integral as the n-th antiderivative, matching derivative. Additive, so 2.1 rather than 2.0.
2. Keep the restriction and remove derivative's three-argument form so the two agree. Breaking, so 2.0 or never.
3. Keep both as they are and document the asymmetry, in Syntax.md and in the exception message, so a caller hitting it is told which arities exist and why.

Option 3 is the cheapest and is worth doing regardless of 1 or 2 — the exception already names the accepted counts, and Syntax.md should agree with it. My weak preference beyond that is option 1, because a caller who writes integral(f, x, 2) after writing derivative(f, x, 2) is not making a mistake, they are generalising correctly from the neighbouring function.

Whichever way it goes, a test should record it, since right now nothing does.

[Rafael-SOWNet]

Correcting this issue — most of its framing was wrong, and the remaining gap is much smaller than I described.

I claimed the three-argument integral was lost undocumented and untested. Both halves are false.

It was deliberate. git log -S finds the change:

1aaa9255  2026-01-21  Add C to integration result, change integral node to support range
                      instead of iterations, ... (#657)

The three-argument form was not dropped to make room for something — it was replaced, on purpose, by the range form. "Range instead of iterations" is exactly the change, stated in the commit.

It is tested. FromStringTest.cs:282, and it predates my reading of the file:

[Fact] public void TestInvalidArg3() => Assert.Throws<FunctionArgumentCountException>(() => FromString("integral(x, x, 4)"));

So there is a test recording the new arity as intended. My "the change has no test recording that it was intended" was wrong — I asserted it after grepping for the exception type and not reading far enough down the same file. The four-argument form is covered too, in FromStringTest.cs:160, ToSymPyTEst.cs:40 and IntegrationTest.cs:210.

Syntax.md is not silent either. Line 111 already reads derivative(expr, var, order), integral(expr, var). The asymmetry is written down; I said it was not.

What is actually left

Two things, both smaller than what I filed:

1. Syntax.md omits the definite form. It lists integral(expr, var) and stops, but integral(expr, var, from, to) is supported and tested. A caller reading the syntax document is told the two-argument form exists and given no way to discover the four-argument one — which is the form the three-argument one was replaced by.

2. 1.3.0 → 1.4.0 upgraders got nothing. BREAKING-CHANGES.md begins at "2.0.0 — since 1.4.0", so a break introduced by 1.4.0 has no home in it. This is not hypothetical: both repository samples called integral(f, x, 1) and have thrown against 1.4.0 since January.

So options 1 and 2 in the issue above should be disregarded. Restoring the three-argument form would undo a deliberate design change, and removing derivative's would be a breaking change made on a false premise. What is left is the documentation half of option 3, which I am fixing.

The lesson is one this repository already writes down: I measured the behaviour across three published versions carefully and then did not spend the same care on whether it was intended. A git log -S on the failing string would have answered it in one command, before the issue was filed.