Compromisos Positivos de ISA S.A

Most consistency algorithms can be viewed as being ‘event based’ in that a given constraint removes a value in the domain of a variable in its scope requiring some other constraints to be considered. The arc-consistency algorithm AC5 is one of an example of an event-based consistency algorithm [Hentenryck et al., 1992].

Vion et al.[2011] fit higher-level consistencies into the same event-based framework by defining a number of abstract constraints depending on how a specific higher-level consistency operates. Each abstract constraint represents a specific combination of element on which the higher-level consistency should operate (e.g., an element in the queue). When this abstract constraint is considered, it executes the higher-level consistency algorithm on that specific combination of elements. In this framework, some of the constraints represent low-level consistency (i.e., AC), others represent

high-level consistency. The technique relies on sorting the constraints to determine the proper order of enforcement. These abstract constraints are not able to enforcing consistency in a ‘when’ strategy (i.e., enforce the consistency during certain parts of the search space), but does allow for easily enforcing a ‘where’ strategy (i.e., enforcing the consistency on a part of the problem).

We propose an alternative approach for enforcing multiple consistencies. Our approach does not involve re-framing the consistency algorithms as events. Rather, it ‘informs’ each consistency algorithm about the changes that have occurred in the problem since the consistency was last enforced.4

Algorithm 1 shows the steps used when a consistency algorithm, consistency, is to be enforced at some depth of the search tree. The algorithm uses the following

Algorithm 1: RunConsistency(consistency,depth)

Input: consistency: A consistency algorithm; depth: Depth of the search tree

1 if consistency 6∈ ranConsistencies[depth] then SaveState(consistency) 2 ranConsistencies[depth] ← ranConsistencies[depth] ∪ {consistency} 3 _{ViewReductions(consistency)}

4 _{Run(consistency)}

methods:

• SaveState(consistency) tells the consistency algorithm consistency that it is at a new level in search, useful for saving its state of the CSP (e.g., save the supports).

• ViewReductions(consistency) passes all of the changes to the problem (i.e., value and tuple deletions) since the last time the consistency algorithm consistency was executed. The idea is that the consistency algorithm uses this information

4_{This framework was initially designed in collaboration with Nathan Stender. It was later refined}

to re-queue any changes for the next time it runs. We discuss below how these changes are stored.

• Run(consistency) executes the consistency algorithm consistency.

In Algorithm 1, ranConsistencies is a global vector of size n that stores, for each search depth, the set of consistency algorithms executed at that depth. Initially all sets in the vector are empty. Line 1 determines whether or not the consistency was previously executed at this depth by checking ranConsistencies, and calls SaveState on the consistency in case it has not been executed before. Line 3 calls ViewReductions on the consistency to alert it of any changes that have occurred since it was last executed.

Every change to the problem (e.g., removing a variable-value pair or a relation- tuple pair) is stored as a reduction.5 _{Every variable (table constraint) is associated}

with an ordered list of value (tuple) reductions that were deleted for that variable (table constraint). Every consistency algorithm stores a pointer to every list of reduc- tions, pointing to the latest reduction processed when the algorithm was last enforced. The method ViewReductions retrieves all the reductions listed after the consis- tency’s current pointer then updates this pointer to point to the end of the list. Note that the reductions retrieved may have occurred at any depth of search deeper than when the consistency was last enforced. If a consistency algorithm caused a reduction, it does not need to view these changes as it caused it, thus its pointer is automatically updated to the end of the list. The typical use of the ViewReductions method is to assist the consistency algorithm in what elements of change to re-queue.

When search undoes an assignment (i.e., when a node visit fails), UndoAssign- ment (Algorithm 2) ‘tells’ the consistency algorithms executed at this search depth to

5_{Storing filtered values as reductions was first proposed by Prosser for the Forward-Checking}

restore the state of the problem. The algorithm UndoAssignment uses the method Algorithm 2: UndoAssignment(depth)

Input: depth: The search depth

1 foreach consistency ∈ ranConsistencies[depth] do 2 _{RestoreState(consistency)}

3 ranConsistencies[depth] ← ∅

RestoreState(consistency), which tells the consistency algorithm consistency that the assignment is undone. RestoreState corresponds to the undo operation of the SaveState call. RestoreState also restores the pointers of the reductions for ev- ery variable and table constraint to the previous level. The restoration of the pointers is accomplished by using a reversible-set data-structure [Demeulenaere et al., 2016].

Summary

In this chapter, we introduced a new approach for visualizing the progression of search by summarizing the number of backtracks and the number of calls to consistency at each depth in the search tree. We also discussed two design mechanisms for imple- menting this visualization.

Chapter 4

A Reactive Strategy for High-Level

Consistency During Search

Enforcing a higher-Level Consistency (HLC) can be between 2–40 times slower than enforcing GAC algorithms. Thus, enforcing HLC needs to reduce the number of node visits by this same amount for enforcing HLC to yield CPU time improvements. Alternatively, instead of enforcing HLC at every step in search we can selectively enforce it.

Our motivation comes from noticing that using the variable-ordering heuristic dom/wdeg [Boussemart et al., 2004] with GAC algorithms is able to solve many problems with little search. In these situations, we want to exploit the easiness of the problem by letting GAC solve the problem and not enforcing HLC.

In this chapter, we present PrePeak+_{as a reactive strategy that operates on the}

two dimensions ‘when’ and ‘how much.’ In particular, (a) we introduce a triggering strategy, PrePeak, that tracks search performance and triggers HLC when search starts thrashing (i.e., when), and (b) choose to enforce HLC on a fraction of the (or- dered) propagation queue and within a bounded time duration (i.e., how much). We

validate our approach on benchmark problems using Partition-One Arc-Consistency as an HLC. However, our strategy is generic and can be used with other higher-level consistency algorithms, as we show in future chapters.

4.1

When HLC: A Trigger-Based Strategy

We first introduce our HLC-triggering strategy, PrePeak. Then we discuss using geometric laws to allow PrePeak to react to the effectiveness of enforcing HLC.