Skip to content
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

Attempt to remove function evaluateLagrangeOne. #1827

Conversation

philippecamacho
Copy link
Contributor

Closes #1752

This PR:

Still draft PR. This is an attempt to remove the function evaluateLagrangeOne. While all the Plonk verifier tests are passing, some PolynomialEval tests are still failing. Not clear to me why.

@philippecamacho philippecamacho requested review from alxiong and removed request for sveitser, nomaxg, jbearer, ImJeremyHe and tbro August 6, 2024 22:56
@philippecamacho philippecamacho marked this pull request as draft August 6, 2024 22:56
Copy link
Contributor

@alxiong alxiong left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

so the cost of evaluateLagrangeOne() is roughly 2.5k. not a lot, should we sacrifice cleaner modularity for this?

}
group = mulmod(group, self.groupGen, p);
}
return 0;
return (0, 0);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is wrong logic btw, when vanishingPolyEval == 0, the zeta could be one of the domain element: if it's the first domain element, then lagrange_1_eval = 1

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks. Some tests still fail though.

@philippecamacho
Copy link
Contributor Author

philippecamacho commented Aug 7, 2024

so the cost of evaluateLagrangeOne() is roughly 2.5k. not a lot, should we sacrifice cleaner modularity for this?

I agree, especially after Common Prefix's optimization, the code would look less clear if we removed evaluateLagrangeOne().

So let us keep this function.

@Ancient123 Ancient123 deleted the cp-i16-redundant-function-evaluateLagrangeOne branch August 29, 2024 15:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants