Skip to content

Conversation

@AleksandarZeljic
Copy link
Collaborator

This PR transitions to using Context dependent architecture to store the search state.
This is achieved by using the CD features of PiecewiseLinearConstraints to store their current state in the search.
The SmtCore now uses the PiecewiseLinearConstraint::nextFeasibleCase/markUnfeasible to record the advancement of the search with the PiecewiseLinearConstraints.

This PR:

  • Replaces old SmtCore with the contextDependent implementation which should be mostly equivalent.

bool fullSolveNeeded = true; // denotes whether we need to solve the subquery
if ( restoreTreeStates && smtState )
fullSolveNeeded = _engine->restoreSmtState( *smtState );
fullSolveNeeded = true; //_engine->restoreSmtState( *smtState );
Copy link
Collaborator

Choose a reason for hiding this comment

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

Do we want to fully remove this functionality for now? Maybe we want to also purge this option here:

( "restore-tree-states",
?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Good point, I will remove it altogether as it is obsolete now.

*/
bool isCaseInfeasible( PhaseStatus phase ) const;


Copy link
Collaborator

Choose a reason for hiding this comment

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

Remove empty line

@@ -0,0 +1,257 @@
/********************* */
Copy link
Collaborator

Choose a reason for hiding this comment

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

Remove this and oldSmtCorecpp?

_statistics = statistics;
}

bool PiecewiseLinearConstraint::phaseFixed() const
Copy link
Collaborator

Choose a reason for hiding this comment

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

When _cdPhaseStatus is not null, does this method always have the same output as isImplication()? If so do we want to merge the two methods?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Longterm we want to merge the two methods. This PR already does a lot and I didn't want to complicate things further, since I am not convinced that this would be a trivial change (e.g. Max/Disjunction semantics). PhaseFixed currently is derived from bound propagation while isImplication is derived from search/backtracking.

dc.notifyUpperBound( 2, 10 );

TS_ASSERT( !dc.phaseFixed() );
TS_ASSERT( !dc.isImplication() );
Copy link
Collaborator

Choose a reason for hiding this comment

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

Do we want to also check phaseFixed() iff isImplication()?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

No the semantics actually differ. Disjunction does not ever explicitly fix the phase, it actually used a test that is exactly the implementation of isImplication. Therefore I removed the special implementation of DisjunctionConstraint::phaseFixed() and replaced the calls with isImplication().

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants