The determinant is computed by fraction-free elimination where it can be (#999)

[Rafael-SOWNet]

Closes #999.

The ceiling, removed

Both arms built from source on one machine:

	before	now
numeric 8×8	382 ms	under 1 ms
numeric 10×10	14 415 ms	2 ms
numeric 11×11	did not return in four minutes	2 ms
numeric 12×12	did not return	3 ms
numeric 20×20	did not return	11 ms
numeric 30×30	did not return	22 ms

Bareiss' fraction-free elimination runs wherever the entries are polynomials over the rationals; Laplace answers everything else. The switch is decided by the entries, not by n — as the issue asks, since a 12×12 with two variables and a 4×4 with sixteen are different problems. It is settled per matrix, by trying.

The elimination was already in the repository

PolynomialResultant.SylvesterDeterminant is a Bareiss elimination over MultivariatePolynomial, written for the Sylvester matrix and already carrying exact division, row swaps, sign tracking, a work budget and a cancellation check. It is split out into FractionFreeDeterminant and shared rather than written twice.

That is worth stating rather than doing quietly: a sign convention or an off-by-one in an elimination is a wrong answer that looks entirely plausible, and one implementation exercised by two callers is tested by both.

The condition question, which is the one the issue says to check rather than argue

exactness is a fact about the ring, not something Entity division notices: (a * b) / a stays written as a quotient unless something cancels it

Right — and the answer is that this arithmetic never touches Entity division. It happens in MultivariatePolynomial, which has no quotients to leave behind at all, and DivideExact returns null rather than a remainder. So a division that does not come out stops the elimination and sends the caller to Laplace. The answer is a polynomial in the entries, or it is Laplace's; there is no third outcome in which a quotient survives to exclude a point.

That is the property #992 was about, and it is why Determinant used Laplace in the first place: an ordinary Gaussian elimination leaves its pivots as literal divisions, so its answer is undefined wherever a pivot vanishes — at points where the determinant is perfectly well defined.

What it declines

Each is a refusal to try, not a wrong answer, and Laplace answers all of them exactly as before:

• an entry that is not a polynomial over the rationals — sin(x), 1 / x, 2 ^ x
• more than eight indeterminates, which is what the packed monomial holds
• a matrix mentioning e or pi: a constant is a value, not an indeterminate, and this ring cannot hold one

Measured

The two algorithms agree on 300 generated matrices where both apply, with no disagreements — compared as a difference that simplifies to zero rather than as trees, since they group the same polynomial differently and that is not a disagreement. The test also asserts it read more than a third of what it generated, so a change that made the elimination decline everything fails here rather than passing vacuously.

The printed form of a symbolic determinant changes, because an elimination produces an expanded polynomial where Laplace produces a nested one. Recorded in BREAKING-CHANGES.md with both arms measured. The expression is no larger in any case measured:

	before	now
[[a, b], [c, d]]	a * d + -b * c	a * d - b * c
[[x, 1, 0], [1, x, 1], [0, 1, x]]	x * (x ^ 2 + -1) + -x	x ^ 3 - 2 * x
[[x, 1], [1, x]], [[1/2, 1/3], [1/4, 1/5]]		unchanged

Failed: 0, Passed: 9154, Skipped: 14 locally on net10.0.

One thing found on the way

Collecting the matrix's variables by name and rebuilding them with MathS.Var throws on names a caller is entitled to have built — x2 parses back as x ^ 2, which is the implicit-power rule the grammar has for a reason. The Variable objects are kept instead.

🤖 Generated with Claude Code

https://claude.ai/code/session_012sonx8iAspMiwRwokT1Ura