Skip to content

Give the quantum factorisation a name that does not collide - #844

Merged
Rafael-SOWNet merged 1 commit into
masterfrom
refactor/tensor-factorize
Aug 9, 2026
Merged

Give the quantum factorisation a name that does not collide#844
Rafael-SOWNet merged 1 commit into
masterfrom
refactor/tensor-factorize

Conversation

@Rafael-SOWNet

Copy link
Copy Markdown
Collaborator

Closes #843, taking option 1 from that issue.

The collision

Two public methods, one letter apart, unrelated operations, identical shapes:

member operation
Entity.Factorize(int level = 2) algebraic factoring of an expression
MathS.Quantum.Factorise(Entity) tensor factorisation of a quantum state

Nothing but the name distinguished them, and the name barely did.

Why not just Factorize

That fixes the spelling and makes the API worse — two public Factorize methods doing unrelated things. MathS.Quantum already holds the inverse operation as TensorExpand, so:

MathS.Quantum.TensorFactorize(state)   // superposition -> tensor product
MathS.Quantum.TensorExpand(state)      // tensor product -> superposition

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 that Factorise was the last one was wrong.

It is renamed to IsNormalized here. 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

  • The internal Factorisation class becomes Factorization and its method follows the public one — it is that member's implementation, so they should not disagree.
  • AsymptoticSeries has a private Normalised that 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.md also 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.txt for this PR:

-AngouriMath.MathS+Quantum.Factorise(AngouriMath.Entity) : AngouriMath.Entity
-AngouriMath.MathS+Quantum.IsNormalised(AngouriMath.Entity) : System.Nullable<System.Boolean>
+AngouriMath.MathS+Quantum.IsNormalized(AngouriMath.Entity) : System.Nullable<System.Boolean>
+AngouriMath.MathS+Quantum.TensorFactorize(AngouriMath.Entity) : AngouriMath.Entity

Two members out, two in, nothing else moved.

Passed! - Failed: 0, Passed: 6050, Skipped: 14, Total: 6064 - UnitTests.dll (net10.0)

AngouriMath, UnitTests, AngouriMath.FSharp and AngouriMath.CPP.Exporting all build with 0 errors.

After this

The public surface has one spelling throughout, and it is checkable rather than asserted — PublicApi.txt contains no -ise, -ised or -isation member.

🤖 Generated with Claude Code

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>
@Rafael-SOWNet
Rafael-SOWNet merged commit c09055f into master Aug 9, 2026
25 checks passed
@Rafael-SOWNet
Rafael-SOWNet deleted the refactor/tensor-factorize branch August 9, 2026 13:57
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

MathS.Quantum.Factorise collides with Entity.Factorize and needs a distinguishing name in 2.0

1 participant