Skip to content

Factorize reaches inside a product the rules already made - #1095

Merged
Rafael-SOWNet merged 1 commit into
masterfrom
fix/factorize-reaches-inside-a-product
Aug 27, 2026
Merged

Factorize reaches inside a product the rules already made#1095
Rafael-SOWNet merged 1 commit into
masterfrom
fix/factorize-reaches-inside-a-product

Conversation

@Rafael-SOWNet

Copy link
Copy Markdown
Collaborator

A follow-up to #1094, fixing an incompleteness that PR introduced.

#1094 asks the polynomial layer only where the rewrite rules said nothing, so that an answer
the rules already gave is never replaced — the order two factors come out in is arbitrary and
theirs is the one on record. Declining a product outright was too broad for that goal.

The rules take a numeric content out and hand back 2 * (x ^ 3 - 1). That is a product, so the
layer declined it — and the remainder is exactly the shape #1018 is about.

before now
"2 * x3 - 2".Factorize() 2 * (x ^ 3 - 1) 2 * (x - 1) * (x ^ 2 + x + 1)
"3 * x6 - 3".Factorize() 3 * (x ^ 6 - 1) five factors
"5 * x7 - 5".Factorize() 5 * (x ^ 7 - 1) 5 * (x - 1) * (x ^ 6 + … + 1)
"y * (x3 - 1)".Factorize() y * (x ^ 3 - 1) y * (x - 1) * (x ^ 2 + x + 1)
"2 * x4 - 10 * x2 + 8".Factorize() four factors and a 2 unchanged
"x * y + x".Factorize() x * (1 + y) unchanged

Each factor is asked separately instead of the product being handed over whole. Every factor the
rules found survives; only the ones they could not split are split.

How it was found, which is the part worth keeping

By asking of Factorize the property #1092 was about — that the answer multiplies back to what it
factored — and noticing a row that satisfied it and was still wrong.

2 * (x ^ 3 - 1) is perfectly equal to 2 * x ^ 3 - 2. The value check says nothing. What was
wrong was not the value but the stopping point, and a property test does not ask about that
unless it is told to. The new test asserts the number of factors as well as the value, for exactly
that reason.

Full suite: 8751 passed, 0 failed.

🤖 Generated with Claude Code

https://claude.ai/code/session_01Bjumi5K7fg8yx6UK1mZTQd

#1094 asks the polynomial layer only where the rewrite rules said nothing, so that an
answer the rules already gave is never replaced -- the order two factors come out in is
arbitrary and theirs is the one on record. Declining a **product** outright was too broad
for that goal.

The rules take a numeric content out and hand back `2 * (x ^ 3 - 1)`. That is a product,
so the layer declined it, and the remainder is exactly the shape #1018 is about. Every
polynomial with a numeric content whose remainder needs the layer stopped one step short:
`2 * x^3 - 2`, `3 * x^6 - 3`, `5 * x^7 - 5`.

Each factor is asked separately now instead of the product being handed over whole. Every
factor the rules found survives, and only the ones they could not split are split -- so
`2 * x^4 - 10x^2 + 8`, which the rules factor in full, is unchanged, and so is
`x * (1 + y)`.

Found by asking of `Factorize` the property #1092 was about -- that the answer multiplies
back to what it factored -- and noticing a row that *satisfied* it and was still less
factored than it should be. The value check said nothing because `2 * (x ^ 3 - 1)` is
perfectly equal to `2 * x ^ 3 - 2`; what was wrong was not the value but the stopping
point, which is a thing a property test does not ask about unless it is told to.
@Rafael-SOWNet
Rafael-SOWNet merged commit a2edfc3 into master Aug 27, 2026
31 checks passed
@Rafael-SOWNet
Rafael-SOWNet deleted the fix/factorize-reaches-inside-a-product branch August 27, 2026 18:21
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.

1 participant