Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

MSM: add rangecheck4 and rangecheck15 lookups in constraints #1976

Merged
merged 1 commit into from
Mar 14, 2024
Merged

MSM: add rangecheck4 and rangecheck15 lookups in constraints #1976

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
25 changes: 20 additions & 5 deletions msm/src/serialization/constraints.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -6,7 +6,8 @@ use kimchi::circuits::{

use crate::{columns::Column, expr::E, serialization::N_INTERMEDIATE_LIMBS, N_LIMBS};

use super::interpreter::InterpreterEnv;
use super::Lookup;
use super::{interpreter::InterpreterEnv, LookupTable};

pub struct Env<Fp> {
/// An indexed set of constraints.
Expand All @@ -15,13 +16,17 @@ pub struct Env<Fp> {
/// folding for instance.
pub constraints: Vec<(usize, Expr<ConstantExpr<Fp>, Column>)>,
pub constrain_index: usize,
pub rangecheck4_lookups: Vec<Lookup<E<Fp>>>,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if it is really a good idea to have the lookups split into different variable names. Looks more general to have just a single lookups vector, and then all of them get pushed into it.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, probably we should think of a way to generalize them to just have one. And then if you really need the distinction of different tables, think of a different way to split them but "inside" the lookup type/vector/struct/whatever. Maybe for a follow up.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, agreed. This is ugly atm, and we must generalize. Let's do it quickly after everything works.

pub rangecheck15_lookups: Vec<Lookup<E<Fp>>>,
}

impl<Fp: PrimeField> Env<Fp> {
pub fn create() -> Self {
Self {
constraints: vec![],
constrain_index: 0,
rangecheck4_lookups: vec![],
rangecheck15_lookups: vec![],
}
}
}
Expand Down Expand Up @@ -63,12 +68,22 @@ impl<F: PrimeField> InterpreterEnv<F> for Env<F> {
Column::X(3 + j)
}

fn range_check15(&mut self, _value: &Self::Variable) {
// TODO
fn range_check15(&mut self, value: &Self::Variable) {
let one = ConstantExpr::from(ConstantTerm::Literal(F::one()));
self.rangecheck15_lookups.push(Lookup {
table_id: LookupTable::RangeCheck15,
numerator: Expr::Atom(ExprInner::Constant(one)),
querolita marked this conversation as resolved.
Show resolved Hide resolved
value: vec![value.clone()],
})
}

fn range_check4(&mut self, _value: &Self::Variable) {
// TODO
fn range_check4(&mut self, value: &Self::Variable) {
let one = ConstantExpr::from(ConstantTerm::Literal(F::one()));
self.rangecheck4_lookups.push(Lookup {
table_id: LookupTable::RangeCheck4,
numerator: Expr::Atom(ExprInner::Constant(one)),
value: vec![value.clone()],
})
}

fn constant(value: F) -> Self::Variable {
Expand Down