23 Commits

Author SHA1 Message Date
Daniel Lubarov
f929f94626
Have rustfmt group imports (#60)
* Have rustfmt group imports

See `rustfmt.toml`; the rest is automated changes.

* fmt
2021-06-10 14:10:35 -07:00
Daniel Lubarov
60f3773a23
Try to simplify open_plonk and fri_combine_initial a bit more (#59)
* Try to simplify open_plonk and fri_combine_initial a bit more

- Use `alpha.powers()` in `open_plonk` instead of the more "manual" approach
- No more "manually" reducing with `alpha_powers`; now using helper methods for that.
- Renaming & other small tweaks

* Remove type hint

* Feedback
2021-06-09 16:17:56 -07:00
Daniel Lubarov
6e83d956e9 Finish up 2021-05-19 23:03:52 -07:00
wborgeaud
78f71672a3 Change Field::exp to using a u64 power. 2021-05-19 12:17:43 +02:00
wborgeaud
96a880193c Clippy 2021-05-18 16:09:22 +02:00
wborgeaud
a2cf2c03b6 Working FRI with field extensions 2021-05-18 15:22:06 +02:00
Daniel Lubarov
7f445686ee Tweaks 2021-05-13 15:44:36 -07:00
Daniel Lubarov
6d03dd06f5 Finish merging in old_polynomial 2021-05-13 15:35:26 -07:00
Daniel Lubarov
b7acdb36ca Merge pull request #36 from mir-protocol/poly_port
Some cleanup related to the two polynomial APIs
2021-05-12 10:55:43 -07:00
Daniel Lubarov
4d5ea83325 polynomial_long_division -> polynomial_division 2021-05-10 14:32:17 -07:00
Daniel Lubarov
8b309fef41 Tweak 2021-05-10 14:30:18 -07:00
Daniel Lubarov
44a5e0be1b Some cleanup related to the two polynomial APIs
Porting over some code from `old_polynomial`, and changing `ListPolynomialCommitment` to use the newer API.

There's one remaining use of `old_polynomial` for long division; I think that can eventually go away when we switch to doing values-only FRI (unless another use comes up).
2021-05-10 13:10:29 -07:00
wborgeaud
ea7926bd95 Update PLONK prover. 2021-05-06 23:14:37 +02:00
wborgeaud
477fe1ea4a Minor fixes 2021-05-06 15:14:43 +02:00
wborgeaud
bb8a68e198 Progress on polynomial commitment 2021-05-03 15:17:05 +02:00
wborgeaud
0fa0942981 FRI on coset 2021-04-30 15:07:54 +02:00
Daniel Lubarov
035d15bc3d Interpolants of arbitrary (point, value) lists
Closes #10. This combines Lagrange interpolation with FFTs as mentioned there.

I was previously thinking that all our polynomial encodings might as well just use power-of-two length vectors, so they'll be "FFT-ready", with no need to trim/pad. This sort of breaks that assumption though, as e.g. I think we'll want to compute interpolants with three coefficients in the batch opening argument.

I think we can still skip trimming/padding in most cases, since it the majority of our polynomials will have power-of-two-minus-1 degrees with high probability. But we'll now have one or two uses where that's not the case.
2021-04-24 19:20:18 -07:00
Daniel Lubarov
af4c8734ce Address some clippy warnings 2021-04-23 12:35:19 -07:00
wborgeaud
6b407e45ef Progress on FRI 2021-04-21 22:31:45 +02:00
Daniel Lubarov
5fe8d633b6 Split main into multiple binaries
... and other minor refactoring.

`bench_recursion` will be the default bin run by `cargo run`; the otheres can be selected with the `--bin` flag.

We could probably delete some of the other binaries later. E.g. `field_search` might not be useful any more. `bench_fft` should maybe be converted to a benchmark (although there are some pros and cons, e.g. the bench framework has a minimum number of runs, and isn't helpful in testing multi-core performance).
2021-04-06 13:23:47 -07:00
Daniel Lubarov
c25c689ef0 More tests, ported from plonky1 2021-04-02 17:49:57 -07:00
Daniel Lubarov
3c262a8c49 Fix some warnings 2021-03-30 20:16:20 -07:00
Daniel Lubarov
6c8dfb97ac Refactor polynomial code 2021-03-30 13:30:31 -07:00