My recent change made `padded` panic if the padded length is less than the current length. I figured that might indicate that something unexpected was going on, so might be good to fail fast.
It looks like `inv_mod_xn` was relying on the old `padded` behavior, and it seems correct AFAIK, i.e. in this case it wasn't a symptom of anything going wrong.
We could also restore the old behavior of `padded` if you prefer; let me know if you have a preferennce.
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).
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.
... 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).
