This is detecting the case where we multiply something by 1 and add 0. In that case we can just return the thing being multiplied by 1. We were using the wrong constant to detect this.
Reduces the cost of `compute_evaluation` from 8 to 6 gates.
We previously checked for special cases, like arithmetic on constant Targets, in `arithmetic`. We can handle those cases without actually adding an `ArithmeticGate`.
Now that `arithmetic` just calls `arithmetic_extension`, it makes more sense to check for special cases in the latter method, so it applies to both base and extension field arithmetic.
Reduces gate count from 16149 to 15689.
No functional changes here. The biggest change was moving certain files into new directories like `plonk` and `iop` (for things like `Challenger` that could be used in STARKs or other IOPs). I also split a few files, renames, etc, but again nothing functional, so I don't think a careful review is necessary (just a sanity check).
We have two division methods: one "unsafe" one, which permits 0/0 = anything, and one "safe" one, for which 0/0 results in an unsatisfiable instance. The latter is slightly more expensive.
I switched a few calls over to safe division, where unsafe division didn't seem sound (or at least it wasn't obvious). For calls where unsafe division did seem sound, I added comments explaining why.
Closes#97.
* Have add_gate take a generic type instead of GateRef
There are a couple advantages
- Users writing their own gates won't need to know about the `GateRef` wrapper; it's more of an internal thing now.
- Easier access to gate methods requiring `self` -- for example, `split_le_base` can just call `gate_type.limbs()` now.
* Update comment
* Always insert
