-
Notifications
You must be signed in to change notification settings - Fork 94
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Arrabiata: prepare constraints for cross-terms computation #2702
base: master
Are you sure you want to change the base?
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## dw/improve-from-variable-implementation #2702 +/- ##
===========================================================================
+ Coverage 72.54% 72.60% +0.05%
===========================================================================
Files 247 247
Lines 57691 57955 +264
===========================================================================
+ Hits 41853 42076 +223
- Misses 15838 15879 +41 ☔ View full report in Codecov by Sentry. |
4f07a8a
to
f713363
Compare
a35fa79
to
0ef15d6
Compare
70addbd
to
0129e25
Compare
0129e25
to
32a4f93
Compare
32a4f93
to
97fbed5
Compare
97fbed5
to
9eff145
Compare
0b6dd27
to
594f689
Compare
6b94b8b
to
bb75668
Compare
9f866ce
to
9b7b501
Compare
9b7b501
to
4b0fd17
Compare
We do suppose evaluations of the public inputs will be given after the witness.
4b0fd17
to
1e9e66c
Compare
We do suppose evaluations of the public inputs will be given after the witness.
It does depend on maximum degree given in parameter. The probability is not negligible if 2 is given.
And use it to generate random monomials.
7e956d0
to
c23758f
Compare
/// All polynomials are supposed to be given as multivariate polynomials of the | ||
/// same degree and the same number of variables, even if they do not have the | ||
/// same number of variables nor the same degree. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is this an invariant the caller needs to respect ?
let mut cross_terms = HashMap::new(); | ||
polys.into_iter().enumerate().for_each(|(i, poly)| { | ||
let cross_terms_poly: HashMap<usize, F> = poly.compute_cross_terms(&eval1, &eval2, u1, u2); | ||
cross_terms_poly.into_iter().for_each(|(p, value)| { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would change the name of the p variable
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
p
is for power
, which is the power of r
.
polys: Vec<T>, | ||
combiner1: F, | ||
combiner2: F, | ||
eval1: [F; N], | ||
eval2: [F; N], | ||
u1: F, | ||
u2: F, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I m not sure I understand what is computed here ?
the text mentioned combining the polys with one combiner, and we have two of them here.
I understand that the two combiners are the alpha from each instances we fold ?
But then I don't get the assymetrical role ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
|
||
// This test is mostly an example to show to compute the cross-terms when we do | ||
// have the expressions, and some evaluations. | ||
// It doesn't test anything in particular. It is mostly an "integration" test. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A way to make this test test thing would be to checked the cross term property
poly(a +r*b) = poly(a) + r^n poly(b) + \sum_i r^i cross_term_i(a,b)
Also a nit: I wouldn't call that an integration test
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"Also a nit: I wouldn't call that an integration test"
That's the reason "integration" is double quoted.
// Computing α'^i * value, and adding it to the next power of r | ||
let alpha_i = combiner2.pow([i as u64]); | ||
// Handling 0^0 = 1 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
isn't combiner a random term that cannot be zero ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, but it was monstly for the tests (see test directory). I didn't handle it initially. Even if the case is negligible, I think it is ok to have it. Maybe we should fail instead?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd ignore it to simplify the code, and remove the testing with zero, but do as you feel
/// It is useful when the number of nested loop is large and the size of the | ||
/// loops is large as well. `filter_map` is used to avoid computing the indices | ||
/// that are not needed and avoid a `capacity_overflow` error. | ||
pub fn compute_indices_nested_loop_upper_bound( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would not expose this function, keep this implementation, and expose compute_indices_nested_loop implemented with that implementation, while computing the upper bound on the fly with a max.
Then we have one function instead of two, which is the efficient variant, and only need one argument
I could not convinced my self of the correctness of the algorithm, and there is no test that reassure me. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd like a test on the defining property of cross terms to convince me of the correctness of the algorithm, which I wasn't able to check manually
/// linearly combined using the power of a combiner, often called `α`. | ||
/// Powers of the combiner are considered as an additional variable of the | ||
/// multi-variate polynomials, therefore increasing the degree of the sum of all | ||
/// polynomials by one. In other words, if we combine (M + 1) polynomials |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See the comment just above:
/// Powers of the combiner are considered as an additional variable of the
/// multi-variate polynomials, therefore increasing the degree of the sum of all
/// polynomials by one.
Instead of having a power, we do consider them as a different variable.
/// cross-terms of the polynomial: | ||
/// | ||
/// ```text | ||
/// P(X_1, ..., X_N, α_1, ..., α_M) = P_1(X_1, ..., X_N) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See https://hackmd.io/@dannywillems/Syo5MBq90#Computation-of-cross-terms-for-shifted-polynomials. And we also discussed it in the past in person. Agreed to have more comments and more PBT. |
This pull request prepares the constraints to compute the cross-terms after the different columns and arguments have been computed. Challenges must be treated as a variable, and will be in a future PR.
Previous attempt: #2695