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

Add support for replace_re #102

Merged
merged 2 commits into from
Nov 15, 2023
Merged

Add support for replace_re #102

merged 2 commits into from
Nov 15, 2023

Conversation

jurajsic
Copy link
Member

@jurajsic jurajsic commented Oct 18, 2023

Simple axiomization for replace_re. Needs to run experiments.

@jurajsic jurajsic linked an issue Oct 18, 2023 that may be closed by this pull request
@jurajsic jurajsic marked this pull request as ready for review November 10, 2023 12:10
@jurajsic jurajsic requested review from vhavlena and Adda0 November 10, 2023 12:11
Copy link
Collaborator

@Adda0 Adda0 left a comment

Choose a reason for hiding this comment

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

Seems good to me in general. Will approve if the experiments run correctly.

Comment on lines +1521 to +1522
if(axiomatized_persist_terms.contains(e))
return;
Copy link
Collaborator

@Adda0 Adda0 Nov 10, 2023

Choose a reason for hiding this comment

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

Why is this if check necessary? Why can it be run multiple times on the same e?

Copy link
Member Author

Choose a reason for hiding this comment

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

Not completely sure, we have it also in other handle functions. I think z3 can send us the same term multiple times. It might be better to do it in relevant_eh() instead of in every handle function.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Yes, there might be multiple occurrences of the syntactically same predicates/functions.

Copy link
Collaborator

@Adda0 Adda0 Nov 10, 2023

Choose a reason for hiding this comment

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

That makes sense. Thanks for the explanation. Should we move these into the parent handler instead of copying them to every function, as suggested above?

Copy link
Collaborator

Choose a reason for hiding this comment

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

It is possible, but it is not that easy. Negated predicates are in the positive form in fact (sign is given by a Boolean flag). Maybe there are some other problems, not sure now. I would keep it as it is.

Copy link
Collaborator

@Adda0 Adda0 Nov 11, 2023

Choose a reason for hiding this comment

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

OK. Let us just keep this as it is. I consider this conversation to be resolved.

@jurajsic
Copy link
Member Author

On webapp (the only benchmark with replace_re), we now solve 98 instances more (all with replace_re). We have 6 TO (4 for replace_re and 2 for only replace, I have to check what happened there, before we solved those 2) and 316 unknowns (replace_re_all).

@jurajsic
Copy link
Member Author

For the 2 instances with only replace, I think they are chain-free, but for some reason the noodlification explodes leading to TO.

@vhavlena vhavlena merged commit 533ab00 into devel Nov 15, 2023
@vhavlena vhavlena deleted the replace_re branch November 15, 2023 11:10
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.

Support for replace_re
3 participants