-
Notifications
You must be signed in to change notification settings - Fork 96
UniPoly equivalence relation and quotient operations
#106
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
Merged
quangvdao
merged 11 commits into
Verified-zkEVM:main
from
dhsorens:dhsorens/unipoly-quotient-operations
Aug 26, 2025
Merged
Changes from 9 commits
Commits
Show all changes
11 commits
Select commit
Hold shift + click to select a range
180675d
feat: prove equiv_trans for arrays; uses unproved helper lemma matchS…
dhsorens 127404b
feat: initial organization of definitions and lemmas for defining ope…
dhsorens 124e0b0
feat: defined functions for add, sub, and neg that will be lifted
dhsorens ccebd46
feat: first proofs that add, sub, and neg descend thru the quotient. …
dhsorens 53dd848
fix: improve lemmas
dhsorens f79a1e0
feat: refine the lemmas about the relationship between equivalence an…
dhsorens 9b4d40f
feat: redefine equiv to be Trim.equiv bc of existing theory
dhsorens 1423c0e
fix: prove lemma that neg and coeff commute
dhsorens 07ddffd
fix: accidentally deleted popWhile_nil_or_last_false
dhsorens e23a62a
fix: in response to gh feedback, simplify the logic of the proofs of …
dhsorens 276d190
cleanup: remove superfluous open list
dhsorens File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Uh oh!
There was an error while loading. Please reload this page.
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.
@quangvdao the old definition is this one here -- two polynomials are equivalent if, when zero-padded into arrays of the same size, they are equal
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.
Ah yeah. sounds good to me
Also we should think about which of
QuotientUniPolyorUniPolyCshould be "the" way to get equivalence with polynomial. The non-quotient version might be preferable?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.
From what I can tell, that probably depends on what the vision of this repo is (I'm familiar with it, but still new here!). Aesthetically, I quite like
QuotientUniPoly-- butUniPolyCis likely more computation-friendly? Considering this is a repo directly aimed at snarkification/formal verification we might favor the computation (non-quotient) in the long run