Evaluation of computable multivariate polynomials, bundled and over Finsets #
CompPoly records that CMvPolynomial.eval vals respects each ring operation separately
(eval_zero, eval_one, eval_add, eval_mul, eval_C, …), which is what simp/grind
need to normalize a fixed expression. Two things are missing for reasoning about a family
of polynomials: the value of a bare variable, and commutation with Finset.sum / Finset.prod.
Both follow at once from bundling: CMvPolynomial.eval vals is eval₂Hom (RingHom.id R) vals,
so map_sum and map_prod apply verbatim. evalHom records that bundling; the two Finset
lemmas are its immediate corollaries, stated in unbundled form so that call sites can rewrite
without unfolding.
Evaluation at a fixed point, bundled as a ring homomorphism — the identity-coefficient case
of eval₂Hom. This is what gives evaluation the map_* API of a RingHom.
Instances For
Evaluation commutes with a finite sum of polynomials.
Evaluation commutes with a finite product of polynomials.
Transporting a whole polynomial #
The lemmas above are enough for statements about values. A statement about degrees is not
determined by values (two distinct polynomials agree everywhere over a finite field), so it has to
cross the representation boundary at the level of the polynomial itself, through
fromCMvPolynomial. That map is the forward direction of polyRingEquiv, hence a ring
homomorphism, so it too commutes with Finset.sum and Finset.prod.
Bridge from univariate eval-extensionality. Two single-variable
CMvPolynomials over an integral domain that agree on more than $d$ points
of a Finset S are equal, when $d$ bounds the degreeOf 0 of their
difference through the CPolynomial.cmvEquiv bridge.
The hypothesis form matches Schwartz–Zippel usage at call sites: callers
typically have a degree bound on the difference polynomial, not on p and
q individually.