-
Notifications
You must be signed in to change notification settings - Fork 40
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
use quotient domain instead of fri domain wherever applicable #124
Conversation
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.
Great work.
As I am not qualified to assess the math in #114, I am only commenting on the software part.
I don't have an objection to the name "arithmetic domain", but I wonder if all mathematical domains aren't arithmetic in some sense? It might not be a bad name because anyone who dug this deep will know that it must mean something more than that it contains numbers.
You are probably right. The reason for the name is its purpose. As of this PR, the STARK prover performs as much arithmetic as possible over the – well – arithmetic domain. In particular, this means computing the quotients, and any intermediate steps to get the quotients. The (bigger) FRI domain is only used for anything related to FRI. The transition from arithmetic domain to FRI domain happens after the combination codeword has been computed. I'm happy to use a different name. I think neither “quotient domain” nor “combination domain” good names. Maybe someone else has a good idea? |
I like "quotient domain" and would propose to repurpose the term "arithmetic domain" to denote what is currently being called "domain". |
4829f33
to
9a6343c
Compare
9a6343c
to
e656ecd
Compare
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.
Looks good to me. Minor changes requested before merging. Major requested changes requested in #128 .
One more consideration: maybe pure LDE should live on |
I think that's a good idea. We could provide LDE and dual LDE, and accept one (respectively, two) target domains, as well as a number of randomizers to be inserted. If that value is set to 0, pure (dual) LDE is automatically performed. |
It turns out that is has the same difficulty as removing the generic type from |
Remove superfluous parameter `fri_domain`.
Only accept generators of type `BFieldElement`, not any Finite Field. Remove duplicate FRI domain in struct `Stark`.
- consistently name parameters `quotient_domain` - use `prof_start` & `prof_stop` macros consistently Co-authored-by: Alan <alan@neptune.cash>
c85a68e
to
465d42d
Compare
Fix #114