* Draw challenge points from the extension field
* Now building
* Misc
* Default eval_unfiltered_base
* fmt
* A few field settings
* Add to Sage
* Display tweak
* eval_filtered_base
* Quartic in bench
* Missing methods
* Fix tests
* PR feedback
Over quartic field extension (for now). This would be used in our FRI recursive verifier later, for the consistency check.
To summarize the wires,
- `n` inputs for the `n` points to interpolate (don't need `4n` since they'll be in the subgroup of the base field)
- `4n` inputs for the `n` (extension field) values to interpolate
- `4` inputs for the point to evaluate the interpolant at (beta, which will be drawn from the extension field right?)
- `4` outputs for the interpolated value
- `4n` internal wires for the interpolant's coefficients
This definitely isn't the most optimal approach, e.g. we could route in a single "base" point and derive its neighboring points, but just wanted to keep it simple for now.
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.
- At least on my Linux machine, a signiciant amount of time (> 50%) was spent inside
OsRng.
- Likely due to blocking behaviour of the rng devices on Linux.
- thread_rng should not block, but at the same time should provide good
enough rng.
