We don't want to provide a generic `map` function, since that would
enable users to arbitrarily alter the value connected to a given cell.
If a new value is being produced, that should either happen outside of
the context of a cell (e.g. intermediate values from witness generation)
or in the context of a newly-assigned cell.
However, in the case of the `Assigned<F>` type, we do need the ability
to evaluate the deferred inversion in some cases (e.g. to then operate
on the bits of the value). So for this `AssignedCell` specialization, we
provide a pass-through `evaluate()` method that otherwise preserves the
cell-value connection.
In zcash/halo2#383 we altered the bounds on region assignment methods
like `Region::assign_advice` to constrain the value closure's result on
`for<'vr> Assigned<F>: From<&'vr VR>` instead of `VR: Into<Assigned<F>>`.
This had the unintended side-effect that `Assigned<F>` could no longer
be returned from the closure, because we were previously relying on the
implicit `impl From<T> for T` provided by Rust, which no longer fits the
bound. This commit adds the missing from-reference impl to restore
functionality, re-enabling inversion deferrment.
The type inference algorithm seems to have been simplified,
meaning that the combination of T::from(x.into()) doesn't work anymore.
In any case, the code was also incomprehensible to a human, as it's not clear
by which "route" it does the transformation. It took me a few minutes to
figure out it's a `u64`.
These have been replaced by operations on either `poly::Ast` nodes, or
operations directly on chunks of polynomials within a higher-level
parallelism context.
Addition and scalar multiplication are (currently) still used in various
areas of the prover, so those are left in place.
This saves a bunch of `Clone`s and `Drop`s, which were consuming
significant amounts of time in large circuits (Orchard), which meant we
didn't save as much time as we could :)
This currently matches the first region on the row that matches any
input column, which will result in some mismatches. To fix this, we will
need to track the columns of complex selectors.
If the rational would evaluate to zero, we need to ignore it instead of
using its denominator in normal rational addition equations. This fixes
the tests we added in the last two commits.
Jack Grigg
Las Safin
Kobi Gurkan
therealyingtong
Daira Hopwood
HAOYUatHZ
Carlos Pérez