The constant
PolynomialResultant.MaxSylvesterSize = 24, added in #918, bounds deg f + deg g in the main variable. Past it, Resultant declines.
Its doc comment states the reasoning honestly: the elimination is cubic in the size of the Sylvester matrix, so 24 admits a 13824-step worst case, and it admits the discriminant of anything up to degree 12 since deg f + deg f' is 2·deg f - 1.
That is arithmetic about the step count, not a measurement of time or memory. The number was chosen, not measured, and it is recorded here so that it is not mistaken for the latter.
Why the arithmetic is not enough
The step count is only half of it. Each of those steps multiplies two multivariate polynomials, and the cost of one step depends on how many terms the entries carry, which the bound says nothing about. In a genuinely multivariate case the entries can approach MultivariatePolynomial.MaxTerms (512), and a 24-size elimination over entries that large is a different proposition from the univariate case the number was reasoned about.
So the honest position is that 24 may be too generous for wide multivariate input and too mean for univariate input, and nobody has measured which.
What would settle it
- Time and allocation for the elimination across the two axes that actually matter — Sylvester size, and terms per entry — rather than size alone.
- A decision on whether one ceiling can serve both, or whether the bound should be on the product of the two.
- Whether the discriminant of a degree-12 polynomial is a case anyone reaches, which is what fixes the useful end of the range.
MultithreadingFunctional.ExitIfCancelled() is called in both loops, so a caller with a timeout can already abort a slow one; that limits the damage but is not a substitute for knowing the number.
Nothing calls Resultant yet, so this blocks nothing today. It is worth settling before something does — #746 makes measured performance a standing condition rather than a roadmap item, and a constant that was reasoned about rather than measured is exactly what that condition is aimed at.
The constant
PolynomialResultant.MaxSylvesterSize = 24, added in #918, boundsdeg f + deg gin the main variable. Past it,Resultantdeclines.Its doc comment states the reasoning honestly: the elimination is cubic in the size of the Sylvester matrix, so 24 admits a 13824-step worst case, and it admits the discriminant of anything up to degree 12 since
deg f + deg f'is2·deg f - 1.That is arithmetic about the step count, not a measurement of time or memory. The number was chosen, not measured, and it is recorded here so that it is not mistaken for the latter.
Why the arithmetic is not enough
The step count is only half of it. Each of those steps multiplies two multivariate polynomials, and the cost of one step depends on how many terms the entries carry, which the bound says nothing about. In a genuinely multivariate case the entries can approach
MultivariatePolynomial.MaxTerms(512), and a 24-size elimination over entries that large is a different proposition from the univariate case the number was reasoned about.So the honest position is that 24 may be too generous for wide multivariate input and too mean for univariate input, and nobody has measured which.
What would settle it
MultithreadingFunctional.ExitIfCancelled()is called in both loops, so a caller with a timeout can already abort a slow one; that limits the damage but is not a substitute for knowing the number.Nothing calls
Resultantyet, so this blocks nothing today. It is worth settling before something does — #746 makes measured performance a standing condition rather than a roadmap item, and a constant that was reasoned about rather than measured is exactly what that condition is aimed at.