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

Optimisation passes #314

Open
jon-chuang opened this issue Nov 2, 2020 · 1 comment
Open

Optimisation passes #314

jon-chuang opened this issue Nov 2, 2020 · 1 comment

Comments

@jon-chuang
Copy link
Contributor

jon-chuang commented Nov 2, 2020

So to implement outline_lcs, one should just walk the BTreeMap once in order, and tally the counts. However, if we have highly nested lcs, given an LC upper bound of k, the walk complexity is upper bounded by k^n. Alternatively, one can cache the results by storing an intermediate BTreeMap which for each lc index, in turn contains a vec of tuples of index of the nested lcs contained in the given lc and their counts. This walk complexity is then bounded by n*k^2. Then, we do another walk, in order again, to substitute those lcs with more than one occurrence to a single var lc with coeff one pointing to a newly allocated variable constrained to agree with the value of the lc. Then, when this is inlined/converted to matrices, it will lead to the desired result.

Circuit designers should include parameters to control which optimisation passes are run. One should also include an importable zk system specific (groth16/marlin etc) optimisation pass defaults. The optimisation pass registry should be in r1cs-std

@weikengchen
Copy link
Member

The current implementation (here) does not tally indirect counts but only direct counts, which is a shortcut. What do you think?

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

No branches or pull requests

2 participants