Give the resultant a consumer, and publish the polynomial layer (#746 item 43)

[Rafael-SOWNet]

Two halves of #746 item 43, and the first is the one that matters.

(a) The resultant had no caller, and now it has one that needs it

PolynomialResultant — 307 lines with a careful content-extraction argument and a measured work ceiling — was referenced nowhere outside its own file except its unit test, ten days after landing flagged as "on probation until something eliminates a variable with them". Every other file in the layer is wired: PolynomialGcd → Patterns and RationalFunction, PolynomialFactorization → AnalyticalEquationSolver and PartialFractions, PartialFractions → IndefiniteIntegralSolver, RationalFunction → Transformation.Catalogue. Under this issue's own counterweight — infrastructure must be validated by a consumer in the same change — that made it speculative code.

The consumer is polynomial inequalities of degree three and up, which previously threw. AnalyticalInequalitySolver handled linear and quadratic only.

A polynomial has one sign on each open interval between consecutive real roots, so the answer is the union of the intervals where the sign is right — provided the root list is complete. A missed root merges two intervals of opposite sign and reports the wrong half as the solution, which is a wrong answer, not an incomplete one. So completeness has to be established rather than hoped for, and that is what the discriminant is for here:

1. PolynomialFactorization.FactorPrimitive writes the polynomial as a product of powers of irreducibles over ℚ, and verifies the product.
2. The number of real roots of each irreducible factor is read off PolynomialResultant.Discriminant — two or none for a quadratic by its sign; three or one for a cubic; and for a quartic the discriminant together with P = 8ac − 3b² and D = 64a³e − 16a²c² + 16ab²c − 16a²bd − 3b⁴.
3. The ordering of the roots is numeric and therefore checked rather than trusted: the sign of the polynomial at an exact rational point inside each interval is computed in exact arithmetic, and the sequence must flip at every odd-multiplicity root and hold at every even one. The two outer samples sit beyond Cauchy's bound. Any mismatch is a refusal.

Degree five is where it stops, and honestly: an irreducible quintic factor has no real-root criterion and no radical formula either.

Measured on builds of each side, and re-verified independently on this machine:

                            master                              this branch
x^3 - x > 0                 NotSufficientlySupported            (-1; 0) \/ (1; +oo)
x^4 - 5x^2 + 4 > 0                  "                           (-oo; -2) \/ (-1; 1) \/ (2; +oo)
(x - 1)^2 * (x + 2) > 0             "                           (-2; 1) \/ (1; +oo)
x^3 - 2x + 1 > 0                    "                           ((-1 - sqrt(5))/2; (-1 + sqrt(5))/2) \/ (1; +oo)
x^5 - 5x^3 + 4x > 0                 "                           (-2; -1) \/ (0; 1) \/ (2; +oo)
x^4 - 10x^2 + 1 > 0                 "                           three intervals at ±sqrt(5 ± 2 sqrt(6))
x^5 - x - 1 > 0                     "                           still refused, with a message naming the real gap

Checked by 32 point-verified theory cases — 121 rational points each, membership against EvalBoolean — not by printed form.

The suggestion I rejected, with the reason. Discriminant for repeated-root detection in AnalyticalEquationSolver would be decorative: that solver already runs TryFactorIntoIrreducibles, whose SquareFreeDecomposition computes gcd(f, f′) — which detects and divides out multiplicity at any degree, where the discriminant only answers yes/no and only up to the resultant's size budget. The sign table is where the discriminant does work nothing else in the tree does: it is the completeness certificate for a real-root list, and without it the interval endpoints would be a guess.

Rothstein–Trager (item 44) is therefore no longer the argument for keeping the resultant.

(b) MathS.Polynomials

Factor, Gcd, Resultant, Discriminant, SquareFreePart — five members, each with XML documentation and a worked example.

Does it belong in the kernel? Yes, and the argument is that it adds nothing to it. Every one is a thin adapter over code already compiled into AngouriMath.dll and already reached by Simplify, Solve and Integrate. No new machinery ships, the common case pays exactly what it paid before, and the trimmer's picture is unchanged because Simplify/Solve already reference the layer. Item 78 says a large thing landing in the kernel wants the package decision first (now #1008); this lands nothing.

What it does cost is a promise for the rest of 2.x, and that is bought with this issue's own complaint: the layer's genuine limits were previously invisible, showing up as a simplification that quietly did nothing.

Refusals are honest — null means "I could not settle this", never "the answer is the input":

Factor(x*y + y, x)     [multivariate]   = null        <- not "x * y + y"
Factor(sin(x) + 1, x)  [not polynomial] = null
Factor(x^33 - 1, x)    [past degree 32] = null
Gcd(<9 variables>, …)                   = null        <- 8 variables answers
Factor(x^2 + 1, x)     [irreducible]    = x ^ 2 + 1   <- an answer, not a refusal
Discriminant(x^2 + b*x + c, x)          = b ^ 2 - 4 * c

Telling irreducible from declined needed one change inside the layer: PolynomialFactorization.Factor returned null for both. FactorComplete now separates them; Factor is the same computation with the trivial factorisation rejected, and its existing callers are unchanged.

Measured

Suite: 7615 passed, 0 failed, 14 skipped (baseline 7533/0/14) — +82, being 32 inequality cases, 44 surface cases and 6 that moved out of the "not supported" theory. F# wrapper 134/0.

Three tests in KnownLimitsAreNotBugsTest pinned the old refusal and now answer. They moved to TheDegreesThatAreSupportedStillAnswer, and the refusal theory now lists irreducible quintics, which is what the gap actually is.

No regression on solving. Both arms in one session, back to back:

	alloc before	alloc after
SolveEasy	8,852,269 B	8,852,269 B
SolveEasyMedium	95,795 B	95,791 B
SolveMedium	658,066 B	658,066 B
SolveMediumHard	162,305,664 B	162,305,664 B
SolveHard	1,431,857,768 B	1,431,857,336 B

Read the allocation column, not the time column. Byte-identical to within 0.005% on all five — the solving path does the same work, which is the actual answer to "did this regress solving". The timings on that pair moved by up to 9% in both directions with five to eight other agents building on the same 8 cores; ParseEasy, SimplifyEasy and EvalEasy moved by more than any Solve row with identical allocation, which no change here could cause. Nothing is claimed as a speed-up.

PublicApi.txt regenerated: +5 members, +1 type, 0 removals. Sources/Package.Build.props carried a figure of 103 additions since the 2.2.0 baseline that counted those same lines; it was true and this change falsified it, so it now reads 109.

Not done, and why

• No Sturm sequences, no degree ≥ 5. Real-root isolation is separate work; the refusal says so.
• Entity.Factorize() still does not use the polynomial layer. x^4 - 5x^2 + 4 comes back unchanged from it while MathS.Polynomials.Factor splits it into four linear factors. That is a real inconsistency and it lives in Core/Transformations/**, which another branch owned during this work — worth its own issue.
• No PartialFractions on the public surface — it needs a public type for the decomposition, which is a larger promise than five scalar-returning members.

[Rafael-SOWNet]

One commit landed after the description above was written, and it belongs in it — 277aaaa7, a refusal rather than a feature.

The sign table places its sample points from double approximations of the roots, then evaluates the polynomial there in exact arithmetic. A rational root whose numerator dwarfs its denominator by more than a double can express approximates to an infinity, and the midpoints computed from it are nowhere in particular — so the sign sequence would be read at points that have no relation to the intervals they are supposed to be inside.

It is refused now. That keeps the property the rest of the change rests on: every interval endpoint in an answer is one the sign sequence was actually verified across. A sign table built on sample points that drifted is not a weaker answer, it is a wrong one — a missed or misplaced root merges two intervals of opposite sign and reports the wrong half as the solution.

Worth noting because it is the shape of thing this whole change is careful about: the numeric part is used only to order the roots and is checked against exact arithmetic afterwards, and where the numeric part cannot be trusted at all the answer is no answer.