support build virtual polynomials in expression style #937
Conversation
…sion_based_virtualpoly
|
|
||
| impl<E: ExtensionField> Expression<E> { | ||
| pub(super) fn to_monomial_form_inner(&self) -> Self { | ||
| Self::combine(self.distribute()).into_iter().sum() | ||
| pub fn get_monomial_terms(&self) -> Vec<Term<Expression<E>, Expression<E>>> { |
There was a problem hiding this comment.
just renaming since "to_xxxx" usually means ownership change, thus get_xxxx more properly
| @@ -895,31 +898,8 @@ impl<'a, E: ExtensionField> MultilinearExtension<E> for RangedMultilinearExtensi | |||
| unimplemented!() | |||
| } | |||
|
|
|||
| fn fix_high_variables(&self, partial_point: &[E]) -> Self::Output { | |||
There was a problem hiding this comment.
this fix_high_variables implementation is unused and actually its wrong, for we need to consider (start,end) due to it's range poly. Thus here clean it up and mark unimplemented!()
| products_sum += AdditiveVec(sum); | ||
| exit_span!(span); | ||
| products_sum | ||
| |mut uni_polys, (_half_eq_opt, MonomialTerms { terms })| { |
There was a problem hiding this comment.
No logic change here. Just rename
'products_sum' -> 'uni_polys'
'coefficient' -> scalar
| products_sum += AdditiveVec(sum); | ||
| exit_span!(span); | ||
| products_sum | ||
| |mut uni_polys, (_half_eq_opt, MonomialTerms { terms })| { |
There was a problem hiding this comment.
same as above
No logic change here. Just rename
'products_sum' -> 'uni_polys'
'coefficient' -> scalar
| @@ -1004,7 +1051,7 @@ pub mod fmt { | |||
| if only_one_limb { | |||
| data[0].to_string() | |||
| } else { | |||
| format!("{name}[{}]", data.join(",")) | |||
| format!("[{}]", data.join(",")) | |||
There was a problem hiding this comment.
we do not need original naming, due to plonky3 field already implement better formatter. This logic is only serve old goldilocks package
To close #936
Design rationales
VirtualPolynomialsBuilderto lift a witness of "ArcPoly" type to expression container, so they can involve into expression domain for calculationVirtualPolynomialsBuilderin tower prover.Either<Base, Ext>typeVirtualPolynomialsBuilderis more like a util function for ceno main sumcheck flow.For GKR layer circuit in gk- iop #799 , the expression system will directly applied on chip-builder and skip
VirtualPolynomialsBuilderbenchmark
there is no impact for e2e benchmark before/after this change, which is expected
2^20
2^21
2^22