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

Parse next as operator #733

Merged
merged 3 commits into from
Nov 2, 2023
Merged

Parse next as operator #733

merged 3 commits into from
Nov 2, 2023

Conversation

chriseth
Copy link
Member

No description provided.

@chriseth chriseth force-pushed the parse_next_as_operator branch from ed672b2 to c2fa193 Compare October 30, 2023 17:38
@chriseth chriseth marked this pull request as draft October 30, 2023 17:40
@chriseth chriseth force-pushed the parse_next_as_operator branch 3 times, most recently from 3347421 to 4aad1d2 Compare October 31, 2023 13:49
chriseth
chriseth commented Oct 31, 2023
View reviewed changes
pil_analyzer/src/condenser.rs Outdated
@@ -160,6 +160,19 @@ impl<T: FieldElement> Condenser<T> {
}
Expression::UnaryOperation(op, inner) => {
let inner = self.condense_expression(inner);
if *op == UnaryOperator::Next {
if let AlgebraicExpression::Reference(reference) = inner {
assert!(!reference.next, "Double application of \"'\"");
Copy link
Member Author

Choose a reason for hiding this comment

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

We could just allow this here and change next: bool to shift: int32 or something. But this would need substantial changes in the witness generator as well.

@chriseth chriseth marked this pull request as ready for review October 31, 2023 15:00
@chriseth chriseth force-pushed the parse_next_as_operator branch 2 times, most recently from 49b57f3 to d36b461 Compare October 31, 2023 15:35
@chriseth chriseth mentioned this pull request Oct 31, 2023
Merged
leonardoalt
leonardoalt reviewed Oct 31, 2023
View reviewed changes
test_data/pil/fib_macro.pil Show resolved Hide resolved
pilopt/src/lib.rs Outdated Show resolved Hide resolved
pil_analyzer/src/pil_analyzer.rs Show resolved Hide resolved
asm_to_pil/src/vm_to_constrained.rs Show resolved Hide resolved
asm_to_pil/src/vm_to_constrained.rs Show resolved Hide resolved
asm_to_pil/src/vm_to_constrained.rs Show resolved Hide resolved
backend/src/pilstark/json_exporter/mod.rs Outdated Show resolved Hide resolved
executor/src/witgen/expression_evaluator.rs Outdated Show resolved Hide resolved
@chriseth
Copy link
Member Author

chriseth commented Nov 1, 2023

Actually let me try to restrict the operators. It makes no sense to allow >> or AlgebraicExpression.

@chriseth chriseth force-pushed the parse_next_as_operator branch from d36b461 to d40cf0a Compare November 2, 2023 09:55
@chriseth chriseth changed the base branch from main to restirct_operators November 2, 2023 09:55
chriseth
chriseth commented Nov 2, 2023
View reviewed changes
ast/src/lib.rs
@@ -72,6 +72,7 @@ pub fn evaluate_unary_operation<T: FieldElement>(op: UnaryOperator, v: T) -> T {
UnaryOperator::Plus => v,
UnaryOperator::Minus => -v,
UnaryOperator::LogicalNot => v.is_zero().into(),
UnaryOperator::Next => panic!("Cannot evaluate \"'\"."),
Copy link
Member Author

Choose a reason for hiding this comment

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

I think it could be fine to actually return v here, but I'm leaving it like that for now.

Base automatically changed from restirct_operators to main November 2, 2023 10:08
@chriseth chriseth force-pushed the parse_next_as_operator branch from d40cf0a to b2a8960 Compare November 2, 2023 10:09
georgwiese
georgwiese reviewed Nov 2, 2023
View reviewed changes
executor/src/witgen/query_processor.rs Show resolved Hide resolved
executor/src/witgen/query_processor.rs Outdated
Expression::UnaryOperation(op, expr) => {
// Special case to allow `x'` for now on witness columns.
// TODO: Check if we actually need this or should replace it by `x(i + 1)`
if let Expression::Reference(Reference::Poly(poly)) = expr.as_ref() {
Copy link
Collaborator

Choose a reason for hiding this comment

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

and if op == UnaryOperation::Next, right?

Copy link
Member Author

Choose a reason for hiding this comment

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

haha yes! :)

@chriseth chriseth force-pushed the parse_next_as_operator branch from e746304 to 50e94d1 Compare November 2, 2023 12:35
@chriseth chriseth force-pushed the parse_next_as_operator branch from 50e94d1 to 9a3c5e0 Compare November 2, 2023 13:45
leonardoalt
leonardoalt approved these changes Nov 2, 2023
View reviewed changes
Copy link
Member

@leonardoalt leonardoalt left a comment

Choose a reason for hiding this comment

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

lgtm, maybe @georgwiese should check the witgen file

@leonardoalt leonardoalt added this pull request to the merge queue Nov 2, 2023
georgwiese
georgwiese approved these changes Nov 2, 2023
View reviewed changes
Copy link
Collaborator

@georgwiese georgwiese left a comment

Choose a reason for hiding this comment

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

LGTM for the witgen part!

Merged via the queue into main with commit 3f7faf1 Nov 2, 2023
2 checks passed
@leonardoalt leonardoalt deleted the parse_next_as_operator branch November 2, 2023 17:29
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@georgwiese georgwiese georgwiese approved these changes

@leonardoalt leonardoalt leonardoalt approved these changes

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
3 participants
@chriseth @leonardoalt @georgwiese