Refactor multi_open APIs #265
Conversation
| @@ -234,7 +237,35 @@ pub trait UnivariatePCS: | |||
| ), | |||
| PCSError, | |||
| > { | |||
| srs.borrow().trim(checked_fft_size(supported_degree)?) | |||
| let fft_degree = checked_fft_size(supported_degree)?; | |||
| srs.borrow().trim(fft_degree).map_err(|e| { | |||
There was a problem hiding this comment.
Technical debt for later: I think cruft such as this can be avoided with thiserror/anyhow. We should be able to automatically build a stack trace using only the ? operator.
There was a problem hiding this comment.
Good point, maybe we can revise later. (Need to improve err reporting as a whole anyway)
| if self.coeffs.len() > domain.size() { | ||
| Err(PrimitivesError::ParameterError( | ||
| ark_std::format!( | ||
| "Polynomial with {} num_of_coeffs can't be evaluated on a smaller domain with size {}", |
There was a problem hiding this comment.
Curious: Why do you no longer support domain size < degree? (I don't think it matters much anyway---most use cases will have domain size >= degree.)
There was a problem hiding this comment.
This is not disallowing num_points < degree, but to ensure domain is proper. When you instantiate multi_open_rou_eval_domain(), you should get a big enough domain. The "truncating to num_points" happen outside (of poly.rs, and in our context, inside univariateKzgPcs impl)
Description
closes: #260
Each commit and commit message should be informative enough, and best reviewed per commit.
Extra note: #260 (comment)
Before we can merge this PR, please make sure that all the following items have been
checked off. If any of the checklist items are not applicable, please leave them but
write a little note why.
Pendingsection inCHANGELOG.mdFiles changedin the GitHub PR explorer