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.

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

[feat] auto carry for field expression #484

Merged
merged 3 commits into from
Oct 4, 2024
Merged

[feat] auto carry for field expression #484

merged 3 commits into from
Oct 4, 2024

Conversation

luffykai
Copy link
Contributor

related to INT-2171

Copy link

linear bot commented Sep 30, 2024

INT-2171 Modular field expression support

This makes me want to have a struct similar to OverflowInt (https://github.com/axiom-crypto/afs-prototype/blob/90a33202d8563938859f822dd2d08965bf6845e9/primitives/src/bigint/mod.rs#L32) but that also can keep a "buffer" of the auxiliary variables like q,r,carries and update the buffer when you carry. The idea is if you use this Fp<AB::Expr> to write an Fp expression, then at the end you can get an AIR that constrains specifically that expression with as many check_carry_mod_to_zero as necessary. lunkai have you thought about this before?

@luffykai luffykai marked this pull request as ready for review October 1, 2024 05:19
}
}

// TODO: rethink about how should auto-save work.
Copy link
Contributor Author

Choose a reason for hiding this comment

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

maybe there is a better way and I am just dumb.
This makes it hard to do, for example x + x because it cannot do 2 mut ref, and we have to clone.

Copy link
Contributor

@jonathanpwang jonathanpwang Oct 3, 2024

Choose a reason for hiding this comment

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

hmmm the cheat is to just make add a function of two Rc<RefCell<FieldVariable<C>>> with the reasoning that if the only time you mutate is to save, then everything is safe. Only do this if it seems worth it to support x + x.
SymbolicExpr::Add will probably need to be changed too

Copy link
Contributor Author

Choose a reason for hiding this comment

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

probably not worth, as x+x can just be x.int_mul(2) actually

@luffykai luffykai requested a review from jonathanpwang October 1, 2024 05:34
FieldVariable::<C>::save_if_overflow(self, other, limb_max_fn);

let limb_max_abs = limb_max_fn(self, other);
let max_overflow_bits = log2_ceil_usize(limb_max_abs);
FieldVariable {
expr: SymbolicExpr::Add(Box::new(self.expr.clone()), Box::new(other.expr.clone())),
Copy link
Contributor

Choose a reason for hiding this comment

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

If at this point, self was auto-saved but other was not, but then later on other is also autosaved, what should the behavior here be?
currently I think it will evaluate using other unsaved since it is a clone, but I guess it is more optimal if it used the autosaved version. I'm not sure which way is easier for the ExpressionBuilder to reason about.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

hmm good point 🤔 but how can this be evaluated with the other being autosaved if that happens later?

Copy link
Contributor

Choose a reason for hiding this comment

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

yea I didn't remember/think through how the implementation currently handles this. if it is such that it can't use autosaved other later, let's just forget about it and note that's something that would require a manual save

Copy link
Contributor

@jonathanpwang jonathanpwang left a comment

Choose a reason for hiding this comment

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

LGTM, but I also added some comments & thoughts around the auto-saving mechanism.

@jonathanpwang
Copy link
Contributor

@luffykai ok to merge then

@luffykai luffykai merged commit 6e1d856 into main Oct 4, 2024
13 checks passed
@luffykai luffykai deleted the lunkai/auto-carry branch October 4, 2024 02:36
luffykai added a commit that referenced this pull request Dec 13, 2024
* add limb info to field variable

* auto carry, but carry bit exceeds range check

* auto carry and tests
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants