Repository navigation
Add up the like terms Expand produces (#164) - #676
Merged
Happypig375 merged 1 commit intoAug 4, 2026
Merged
Conversation
`(x+1)^2 * (x+2-1)^2` expanded to sixteen terms, of which five are distinct. The
issue is titled "cannot be expanded" and that is what it means.
The two of you had already worked out what it needs, on the issue: each term of the
result wants simplifying, but Simplify is far too expensive to call from inside
Expand -- "some kind of fast Simplify that unites terms by their common multiplier".
That is what this is. Each term is reduced to a coefficient and a product of powers,
PowerRules folds (x^2)^2 into x^4 so the two are not counted as different monomials,
and terms whose products agree are added together. Nothing else.
(x+1)^2 * (x+2-1)^2 1 + 4x + 6x^2 + 4x^3 + x^4
((x-1)*(x-2))^3 8 - 36x + 66x^2 - 63x^3 + 33x^4 - 9x^5 + x^6
The second is the case asked for in the same thread.
A term whose coefficients cancel is written out rather than dropped. That looks
wasteful, and it is the whole of the correctness here: the monomial may carry a
domain condition, and (4a - 2)/(2x) + (1 - 2a)/x is zero only where x is not.
Dropping the term collected it to a plain 0 and threw that away. Written out,
InnerSimplified turns 0 * x^-1 back into `0 provided not x = 0`. There is a test.
Four existing expectations change, all to the collected form: 3x + 2x arriving as
5x in ExpandCollapseTest, `a + 3 + 1` as `a + 4` in PolyParser, and two orderings.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #676 +/- ##
==========================================
- Coverage 80.99% 79.99% -1.01%
==========================================
Files 155 156 +1
Lines 13687 12687 -1000
Branches 1957 2075 +118
==========================================
- Hits 11086 10149 -937
+ Misses 1990 1928 -62
+ Partials 611 610 -1 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
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
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.
Closes #164 properly. My
earlier PR #666 added a test for it that asserted
Simplify, and the issue is aboutExpand— that was the wrong test, and the issue rightly stayed open.Sixteen terms, of which five are distinct. "Cannot be expanded" is exactly right.
What it does
You had both already worked out what this needs, on the issue itself: each term of the
result wants simplifying, but
Simplifyis far too expensive to call from insideExpand— "some kind of fast Simplify that unites terms by their common multiplier".That is what this is, and no more. Each term is reduced to a coefficient and a product of
powers;
PowerRulesfolds(x^2)^2intox^4so the two are not counted as differentmonomials; terms whose products agree are added together.
The second is the case @Happypig375 asked for in the same thread.
The part that looks wasteful and is not
A term whose coefficients cancel is written out rather than dropped. That is the whole
of the correctness here. The monomial may carry a domain condition:
is zero only where x is not. Both terms are
c · x⁻¹, the coefficients cancel, anddropping the term collected the whole thing to a plain
0— throwing the condition away.Written out,
InnerSimplifiedturns0 · x⁻¹back into0 provided not x = 0. Anexisting test caught this, and there is now one of my own pinning it.
Four existing expectations change
All to the collected form, which is the point of the change:
ExpandCollapseTest.Factorialx^2 + x*3 + 2*x + 6x^2 + 5*x + 6PolyParser.TestLinear3a + 3 + 1a + 4IntegrationTest.TestIndefiniteCfirstIntegrationTest.TestLnAbsSquaredThe last two are the same expression written differently; the first two are the
collection working.
Testing
UnitTests3892 passed / 0 failed,FSharpWrapperUnitTests127 passed / 0 failed, bothnetstandard2.0andnet7.0build.12 new tests: both cases from the issue, ordinary products, unlike terms across different
variables being left apart, value preservation at points, and the cancelling-terms case
above.
🤖 Generated with Claude Code