Write down integral's two forms, and 1.4.0's unrecorded break - #848
Merged
Conversation
Syntax.md listed integral(expr, var) and stopped. The definite form integral(expr, var, from, to) is supported and covered by tests in three files, but a caller reading the syntax document was told only the two-argument form existed and given no way to discover the other -- which is the form that replaced the three-argument one. It now lists both, and says why derivative takes an order while integral does not: derivative(f, x, 2) is a second derivative, integral's third and fourth arguments are bounds. Three arguments name neither form, which is a parse error rather than an oversight. BREAKING-CHANGES.md begins at 2.0.0, so the change that introduced this -- PR #657 in 1.4.0, replacing the iteration count with a range -- has never had a home in it. 1.4.0 is what dotnet add package installs today and the change is silent until a string is parsed, so it now has a section of its own at the end. Both samples in this repository called integral(f, x, 1) and had been failing against 1.4.0 since January without anyone seeing it, because they were pinned to 1.3.0. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Rafael-SOWNet
added a commit
that referenced
this pull request
Aug 9, 2026
preview.1 is published, and it has the conversion. Every other entry in the file describes a change from 1.3.0 or 1.4.0, so the file's implicit frame is release-to-release and a reader already on preview.1 would not learn from it that this one lands on them. Checked: #848 is the only other commit to touch the file since the preview.1 tag, and what it added is a 1.4.0 section, not a preview delta. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Rafael-SOWNet
added a commit
that referenced
this pull request
Aug 10, 2026
…rloads uncallable (#853) * Drop the implicit List<Entity> conversion that made three params overloads uncallable Entity had implicit conversions to itself from both Entity[] and List<Entity>, each building a FiniteSet. The List one meant a list also converted to a single Entity, so for any member with both an IEnumerable<Entity> overload and a params Entity[] overload the params form became applicable in its expanded form, neither candidate was better, and the call did not compile: var equations = new List<Entity> { "x - 1", "y - 2" }; new EquationSystem(equations); // error CS0121 new FiniteSet(equations); // error CS0121 MathS.Equations(equations); // error CS0121 Not three defects -- one conversion breaking every params Entity[] overload in the library, including any added later. A sweep of all 2602 members in PublicApi.txt for the IEnumerable<T>/T[] overload pattern found exactly these three, and each was confirmed by compiling the call in isolation. The array, IEnumerable<Entity> and variadic forms always compiled; only a concrete List<Entity> broke, which is how it reached a 2.0 preview unnoticed. The Entity[] conversion is kept. An array binds to the params overload in its normal form by an identity conversion, which wins outright, so it never had the ambiguity. The new test compiling is the regression guard: restore the conversion and the test project stops building. Sources/.editorconfig gets a per-file header section for it, since Tests/UnitTests/Common still carries the 2022 template. Verified: 6055 C# tests and 130 F# tests pass, the library, F# wrapper and Utils build clean, and all ten call shapes in the ambiguity matrix now compile. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Say that this break falls between preview.1 and preview.2 preview.1 is published, and it has the conversion. Every other entry in the file describes a change from 1.3.0 or 1.4.0, so the file's implicit frame is release-to-release and a reader already on preview.1 would not learn from it that this one lands on them. Checked: #848 is the only other commit to touch the file since the preview.1 tag, and what it added is a 1.4.0 section, not a preview delta. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Correct which previews carry the conversion preview.2 was tagged while this branch sat unmerged, so it ships the conversion too and the previous commit's "gone from preview.2" is wrong. Naming the version that removes something from a branch that has not merged bets on merge order; the entry now says "the release that follows them" and stops guessing. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The documentation half of #847 — which is all that survives of it, after I corrected the rest of that issue.
What was actually missing
Syntax.md:111listedintegral(expr, var)and stopped. The definite formintegral(expr, var, from, to)is supported and covered by tests in three files (FromStringTest.cs:160,ToSymPyTEst.cs:40,IntegrationTest.cs:210), but a caller reading the syntax reference was told only the two-argument form existed, with no way to discover the other — which is precisely the form that replaced the three-argument one.It now lists both, and says why the two calculus functions read differently:
That asymmetry is real and looks like an inconsistency until you know it is a range rather than a count. Saying so is cheaper than the alternatives I originally proposed in #847, both of which I have since withdrawn.
The 1.4.0 note
BREAKING-CHANGES.mdbegins at "2.0.0 — since 1.4.0", so a break introduced by 1.4.0 has never had a home in it. This one is worth recording because 1.4.0 is whatdotnet add packageinstalls today and the change is silent until a string is parsed:integral(f, x, 1)integral(f, x)FunctionArgumentCountExceptionintegral(f, x, a, b)It gets a short section at the end of the file, with the fix (
integral(f, x, 1)→integral(f, x), identical in meaning).How this was found, and what I got wrong
Both samples in this repository called
integral(f, x, 1)and had been failing against 1.4.0 since January without anyone seeing it, because they were pinned toAngouriMath 1.3.0. #846 unpinned them, which is what surfaced it.I then filed #847 claiming the change was accidental and untested, and proposed restoring the three-argument form. Both claims were false —
git log -Sfinds it as a deliberate design change in #657, andFromStringTest.cs:282has asserted the new arity all along. That correction is on the issue; only the documentation gap survives, and this is it.Documentation-only. No code changes, no behaviour changes.
🤖 Generated with Claude Code