Skip to content

stack_decision_proceduret for solving under assumptions/contexts #4581

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

Merged

Conversation

peterschrammel
Copy link
Member

Replaces #4451 and #4054

  • Each commit message has a non-empty body, explaining why the change was made.
  • Methods or procedures I have added are documented, following the guidelines provided in CODING_STANDARD.md.
  • The feature or user visible behaviour I have added or modified has been documented in the User Guide in doc/cprover-manual/
  • Regression or unit tests are included, or existing tests cover the modified code (in this case I have detailed which ones those are in the commit message).
  • My commit message includes data points confirming performance improvements (if claimed).
  • My PR is restricted to a single feature or bugfix.
  • White-space or formatting changes outside the feature-related changed lines are in commits of their own.

\*******************************************************************/

/// \file
/// Decision procedure with incremental solving with contexts
Copy link
Contributor

Choose a reason for hiding this comment

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

Perhaps give an example of intended usage?

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've added two examples

@@ -365,7 +365,7 @@ bool prop_conv_solvert::set_equality_to_true(const equal_exprt &expr)
return true;
}

void prop_conv_solvert::set_to(const exprt &expr, bool value)
void prop_conv_solvert::do_set_to(const exprt &expr, bool value)
Copy link
Contributor

Choose a reason for hiding this comment

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

Give this a better name, or provide some documentation to advise a future editor on whether they want set_to or do_set_to

Copy link
Member Author

Choose a reason for hiding this comment

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

documentation extended

@@ -124,10 +127,24 @@ class prop_conv_solvert : public conflict_providert,

virtual void ignoring(const exprt &expr);

// deliberately protected now to protect lower-level API
/// Actually adds the constraints to `prop`
Copy link
Contributor

Choose a reason for hiding this comment

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

Explicitly mention that set_to is a wrapper around this, and which one ought to be used

Copy link
Member Author

Choose a reason for hiding this comment

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

made private

Copy link
Contributor

Choose a reason for hiding this comment

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

do_set_to is not a great name, why not naming it add_constraint_to_prop?

{
// We remove the context from the stack.
for(size_t i = 0; i < context_size_stack.back(); ++i)
assumption_stack.pop_back();
Copy link
Contributor

Choose a reason for hiding this comment

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

assumption_stack.resize(assumption_stack.size() - context_size_stack.back())?

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, should work. Shrinking resize doesn't reallocate.


/// Push a new context on the stack
/// This context becomes a child context nested in the current context.
virtual void push() = 0;
Copy link
Collaborator

Choose a reason for hiding this comment

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

Is this equivalent to a push of an empty vector?

Copy link
Member Author

@peterschrammel peterschrammel Apr 29, 2019

Choose a reason for hiding this comment

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

No - clarified in docs

virtual void push() = 0;

/// Pop whatever has been pushed in the last call to `push`
virtual void pop() = 0;
Copy link
Collaborator

Choose a reason for hiding this comment

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

I don't think the documentation is accurate: two calls to pop wouldn't remove the same element? I think the documentation should refer to the top of the stack. And what's the behaviour when stack underflow would occur? Is an implementation expected to handle this gracefully (by ignoring it), or should it fail hard?

propt &prop;

messaget log;

static const char *context_prefix;
Copy link
Collaborator

Choose a reason for hiding this comment

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

Can we just initialise it right here rather than in the implementation file?

Copy link
Member Author

Choose a reason for hiding this comment

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

What would be the advantage of that?

Copy link
Collaborator

Choose a reason for hiding this comment

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

Fewer lines of code and easier to locate. But clearly a nit-pick and all up to you.

prop_conv.set_assumptions(assumptions);
exprt::operandst assumptions;
assumptions.push_back(literal_exprt(c));
prop_conv.push(assumptions);
Copy link
Collaborator

Choose a reason for hiding this comment

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

How about simplifying all this to prop_conv.push({literal_exprt{c}});?

@@ -124,10 +127,24 @@ class prop_conv_solvert : public conflict_providert,

virtual void ignoring(const exprt &expr);

// deliberately protected now to protect lower-level API
/// Actually adds the constraints to `prop`
Copy link
Contributor

Choose a reason for hiding this comment

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

do_set_to is not a great name, why not naming it add_constraint_to_prop?

Provides combined push/pop + assumptions interface
and carry over the current, partial support in smt2_convt.
Remove obsolete method declaration
@peterschrammel peterschrammel force-pushed the stack-decision-procedure branch from 9ae2e3e to bc3837e Compare April 29, 2019 12:50
@peterschrammel peterschrammel merged commit afb3df7 into diffblue:develop Apr 29, 2019
@peterschrammel peterschrammel deleted the stack-decision-procedure branch April 29, 2019 13:57
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.

5 participants