Give the quantum factorisation a name that does not collide - #844
Merged
Conversation
MathS.Quantum.Factorise differed by one letter from Entity.Factorize, which does something else entirely -- algebraic factoring of an expression against tensor factorisation of a quantum state. Both take an Entity and return an Entity, so the name was all that distinguished them. Renaming it to Factorize would have made the spelling uniform and the API worse: two public Factorize methods doing unrelated things. MathS.Quantum already holds the inverse as TensorExpand, so TensorFactorize states the domain and the direction, pairs with its inverse, and ends the collision. The spelling is fixed as a side effect rather than as the point. MathS.Quantum.IsNormalised becomes IsNormalized in the same pass. Auditing the recorded public surface for the rename showed it was still there, and it is public, so 2.0 is equally the last release that can change it. Shipping one British member after two renames made to remove them would have been the wrong outcome. The internal Factorisation class becomes Factorization and its method follows the public one, since it is that member's implementation. AsymptoticSeries has a private Normalised that is deliberately left alone: private names carry no deadline, so there is no reason for a naming change to reach into the limits code. The public surface now has one spelling throughout, and that is checkable rather than asserted -- PublicApi.txt contains no -ise, -ised or -isation member. Its diff for this change is two members out and two in, nothing else. 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
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 #843, taking option 1 from that issue.
The collision
Two public methods, one letter apart, unrelated operations, identical shapes:
Entity.Factorize(int level = 2)MathS.Quantum.Factorise(Entity)Nothing but the name distinguished them, and the name barely did.
Why not just
FactorizeThat fixes the spelling and makes the API worse — two public
Factorizemethods doing unrelated things.MathS.Quantumalready holds the inverse operation asTensorExpand, so:names the domain and the direction, pairs with its inverse, and ends the collision. The spelling is fixed as a side effect rather than as the point.
One addition beyond the issue
Auditing the recorded public surface while doing this turned up
MathS.Quantum.IsNormalised, still British. My claim in #843 thatFactorisewas the last one was wrong.It is renamed to
IsNormalizedhere. It carries no collision, only the spelling — but it is public, so 2.0 is equally the last release that can change it, and shipping one British member after two renames made expressly to remove them would be the wrong outcome. Say the word if you would rather it were split out.The rule I applied to the non-public names
Factorisationclass becomesFactorizationand its method follows the public one — it is that member's implementation, so they should not disagree.AsymptoticSerieshas a privateNormalisedthat is deliberately left alone. Private names carry no deadline; there is no reason for a naming change to reach into the limits code and enlarge the review surface.AGENTS.mdalso says "Factorisation into irreducibles is polynomials only" — prose about polynomial factoring, not this member, and correctly untouched.Measured
The public-surface baseline from #841 makes the blast radius self-reporting. The complete diff of
PublicApi.txtfor this PR:Two members out, two in, nothing else moved.
AngouriMath,UnitTests,AngouriMath.FSharpandAngouriMath.CPP.Exportingall build with 0 errors.After this
The public surface has one spelling throughout, and it is checkable rather than asserted —
PublicApi.txtcontains no-ise,-isedor-isationmember.🤖 Generated with Claude Code