less_than util
#183
less_than util
#183
Conversation
zemse
force-pushed
the
167-util-lt
branch
2 times, most recently
from
62f00a9 to
17f7a7a
Compare
| let name = name_fn(); | ||
| let is_lt = cb.create_witin(|| format!("{name} witin"))?; | ||
| // TODO add name_fn to lookup_ltu_limb8, not done yet to avoid merge conflicts | ||
| cb.lookup_ltu_limb8(is_lt.expr(), lhs, rhs)?; |
There was a problem hiding this comment.
We can't use lookup_ltu_limb8 because this can be only use in lhs/rhs are byte expression. Need to design less_than for general expression, refer lt.rs in zkEVM
There was a problem hiding this comment.
Thanks for the ref, I have made the change, however I think the diff has to be bounded to be < the range. Hence I had to use a ux lookup
zemse
force-pushed
the
167-util-lt
branch
2 times, most recently
from
2df1e21 to
30256ec
Compare
zemse
force-pushed
the
167-util-lt
branch
2 times, most recently
from
1eb74f0 to
7834bda
Compare
| prev_ts: Expression<E>, | ||
| ts: Expression<E>, | ||
| prev_values: &V, | ||
| values: &V, | ||
| ) -> Result<Expression<E>, ZKVMError> { | ||
| ) -> Result<(Expression<E>, ExprLtConfig, ExprLtConfig, ExprLtConfig), ZKVMError> { |
There was a problem hiding this comment.
Wondering if it's possible not to return these three ExprLtConfig, and embeds these lt gadgets inside RegisterChipOperations? If we return these ExprLtConfig to the caller, it means almost all the opcodes need to declare them in their own circuit, like this. It would look more succinct if we manage these three gadgets in this file.
There was a problem hiding this comment.
After discussed with @hero78119, we can do this refactor in the later PR.
| // TODO implement lt gadget | ||
| // let is_lt = prev_ts.lt(self, ts)?; | ||
| // self.require_one(is_lt)?; | ||
| let lt_rs1_cfg = |
There was a problem hiding this comment.
Not this line. As mentioned in L53 this file, I guess register_read needs the logic here as well,
fix fmt prn
remove tests
Closes #167