Repository navigation
integral lost its three-argument form in 1.4.0, undocumented, and now disagrees with derivative #847
Description
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
- Restore three-argument
integralas the n-th antiderivative, matchingderivative. Additive, so 2.1 rather than 2.0. - Keep the restriction and remove
derivative's three-argument form so the two agree. Breaking, so 2.0 or never. - Keep both as they are and document the asymmetry, in
Syntax.mdand 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.
Activity
Build the samples against the source, not a package from two majors a…
Rafael-SOWNet commentedon Aug 9, 2026
Correcting this issue — most of its framing was wrong, and the remaining gap is much smaller than I described.
I claimed the three-argument
integralwas lost undocumented and untested. Both halves are false.It was deliberate.
git log -Sfinds the change: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: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:40andIntegrationTest.cs:210.Syntax.mdis not silent either. Line 111 already readsderivative(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:
Syntax.mdomits the definite form. It listsintegral(expr, var)and stops, butintegral(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.1.3.0 → 1.4.0 upgraders got nothing.
BREAKING-CHANGES.mdbegins 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 calledintegral(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 -Son the failing string would have answered it in one command, before the issue was filed.Put every node type through the pipelines, and hold printing to being…
Say what the three-argument integral actually cost, measured on 1.3.0 (…