1 Introduction
Encoding finite linear Constraint Satisfaction Problems (CSPs; [1, 2]) as propositional formulas and solving them by using modern solvers for Satisfiability Testing (SAT; [3]) has proven to be a highly effective approach, as demonstrated by the awardwinning sugar^{1}^{1}1http://bach.istc.kobeu.ac.jp/sugar system. The CSP solver sugar reads a CSP instance and transforms it into a propositional formula in Conjunctive Normal Form (CNF). The translation relies on the order encoding [4, 5], and the resulting CNF formula can be solved by an offtheshelf SAT solver.
In what follows, we elaborate upon an alternative approach based on Answer Set Programming (ASP; [6]) and present the resulting CSP solver aspartame^{2}^{2}2http://www.cs.unipotsdam.de/wv/aspartame. The major difference between sugar and aspartame rests upon the implementation of the translation of CSPs into Boolean constraint problems. While sugar implements a translation into CNF in the imperative programming language JAVA, aspartame starts with a translation into a set of facts.^{3}^{3}3In practice, aspartame reuses sugar’s frontend for parsing and normalizing CSPs.
In turn, these facts are combined with a generalpurpose ASP encoding for CSP solving (also based on the order encoding), which is subsequently instantiated by an offtheshelf ASP grounder. The resulting propositional logic program is then solved by an offtheshelf ASP solver.
The highlevel approach of ASP has obvious advantages. First, instantiation is done by generalpurpose ASP grounders rather than dedicated implementations. Second, the elaboration tolerance of ASP allows for easy maintenance and modifications of encodings. And finally, it is easy to experiment with novel or heterogeneous encodings. However, the intruding question is whether the highlevel approach of aspartame matches the performance of the more dedicated sugar system. We empirically address this question by contrasting the performance of both CSP solvers, while fixing the backend solver to clasp, used as both a SAT and an ASP solver.
From an ASP perspective, we gain insights into advanced modeling techniques for solving CSPs. The ASP encoding implementing CSP solving with aspartame has the following features:

usage of function terms to abbreviate structural subsums

avoidance of (artificial) intermediate Integer variables (to break sum expressions)

order encoding applied to structural subsum variables (as well as input variables)

encodingwise filtering of relevant threshold values (no blind usage of domains)

customizable “pigeonhole constraint” encoding for alldifferent constraints

“smart” encoding of table constraints, tracing admissible tuples along arguments
In the sequel, we assume some familiarity with ASP, its semantics as well as its basic language constructs. A comprehensive treatment of ASP can be found in [6], one oriented towards ASP solving is given in [7]. Our encodings are given in the language of gringo 3 [8]. Although we provide essential definitions of CSPs in the next section, we refer the reader to the literature [1, 2] for a broader perspective.
2 Background
A Constraint Satisfaction Problem (CSP) is given by a pair consisting of a set of variables and a set of constraint clauses. Every variable has an associated finite domain such that either or ; is a Boolean variable if , and an Integer variable otherwise. We denote the set of Boolean variables in by and the set of Integer variables in by . A constraint clause is a set of literals over Boolean variables in as well as linear inequalities or global constraints on Integer variables in . Any literal in is of the form or , where is either a Boolean variable in , a linear inequality, or a global constraint. A linear inequality is an expression in which as well as all for are Integer constants and are Integer variables in . A global constraint (cf. [9]) is an arbitrary relation over Integer variables in ; we here restrict ourselves to table and alldifferent constraints over subsets of the Integer variables in , where a table constraint specifies tuples of admitted value combinations and alldifferent applies if are assigned to distinct values in their respective domains.^{4}^{4}4Linear inequalities relying on further comparison operators, such as , , , , and , can be converted into the considered format via appropriate replacements [5]. Moreover, note that we here limit the consideration of global constraints to the ones that are directly, i.e., without normalization by sugar, supported in our prototypical ASP encodings shipped with aspartame.
Given a CSP , a variable assignment is a (total) mapping such that for every . A Boolean variable is satisfied w.r.t. if . Likewise, a linear inequality is satisfied w.r.t. if . Table constraints and alldifferent constraints over subsets of are satisfied w.r.t. if or for all , respectively. Any Boolean variable, linear inequality, or global constraint that is not satisfied w.r.t. is unsatisfied w.r.t. . A constraint clause is satisfied w.r.t. if there is some literal (or ) such that is satisfied (or unsatisfied) w.r.t. . The assignment is a solution for if every is satisfied w.r.t. .
Example 1
Consider a CSP with Boolean and Integer variables and , where , and constraint clauses as follows:
(1)  
(2)  
(3) 
The alldifferent constraint in requires values assigned to , , and to be mutually distinct. Respective assignments satisfying the linear inequality in include , , and or , , and , while the table constraint in is satisfied w.r.t. assignments containing , , and or , , and . In view of the Boolean variable , whose value allows for “switching” between the linear inequality in and the table constraint in , we obtain the following solutions for :
3 Approach
The aspartame tool extends the SATbased solver sugar by an output component to represent a CSP in terms of ASP facts. The generated facts can then, as usual, be combined with a firstorder encoding processable with offtheshelf ASP systems. In what follows, we describe the format of facts generated by aspartame, and we present a dedicated ASP encoding utilizing function terms to capture substructures in CSP instances.
3.1 Fact Format
Facts express the variables and constraints of a CSP instance in the syntax of ASP grounders like gringo [8]. Their format is easiest explained on the CSP from Example 1, whose fact representation is shown in Listing 1. While facts of the predicate var/2 provide labels of Boolean variables like , the predicate var/3 includes a third argument for declaring the domains of Integer variables like , , and . Domain declarations rely on function terms range(,), standing for continuous Integer intervals . While one term, range(1,3), suffices for the common domain of , , and , in general, several intervals can be specified (via separate facts) to form noncontinuous domains. Note that the interval format for Integer domains offers a compact fact representation of (continuous) domains; e.g., the single term range(1,10000) captures a domain with elements. Furthermore, the usage of meaningful function terms avoids any need for artificial labels to refer to domains or parts thereof.
The literals of constraint clauses are also represented by means of function terms. In fact, the second argument of constraint/2 in Line 3 of Listing 1 stands for from the constraint clause in (1), which is identified via the first argument of constraint/2. Since every fact of the predicate constraint/2 is supposed to describe a single literal only, constraint clause identifiers establish the connection between individual literals of a clause. This can be observed on the facts in Line 4–7, specifying literals belonging to the binary constraint clauses and in (2) and (3). Here, the terms b and op(neg,b) refer to the literals and over Boolean variable , where op(neg,) is the general notation of for all (supported) constraint expressions . The more complex term of the form op(le,,) in Line 5 stands for a linear inequality . In particular, the inequality from is represented by nested op(add,,) terms whose last argument and deepest part are of the form op(mul,,); such nesting corresponds to the precedence . The representation by function terms captures linear inequalities of arbitrary arity and, as with Integer intervals, associates (sub)sums with canonical labels. Currently, the order of arguments is by variable labels , while more “clever” orders may be established in the future.
The function terms expressing table and alldifferent constraints both include an argument list of the form arg(,arg(,arg(,nil))), in which refer to Integer variables. In Line 3 of Listing 1, an alldifferent constraint over arguments is declared via global(alldifferent,); at present, alldifferent is a fixed keyword in facts generated by aspartame, but support for other kinds of global constraints can be added in the future. Beyond an argument list , function terms of the form rel(,) also include an identifier referring to a collection of table constraint tuples. For instance, the corresponding argument r in Line 7 addresses the tuples specified by the facts in Line 9–12. Here, rel(r,2,3,supports) declares that r is of arity and includes tuples, provided as white list entries via facts of the form tuple(r,,,). The latter include tuple and argument identifiers and along with a value . Accordingly, the facts in Line 10, 11, and 12 specify the pairs , , and of values, which are the combinations admitted by the table constraint from in (3). The application of the table constraint to variables and is expressed by the argument list in Line 7, so that tuple declarations can be reused for other variables subject to a similar table constraint.
3.2 FirstOrder Encoding
In addition to an output component extending sugar for generating ASP facts, aspartame comes along with alternative firstorder ASP encodings of solutions for CSP instances. In the following, we sketch a dedicated encoding that, for one, relies on function terms to capture recurrences of similar structures and, for another, lifts the order encoding approach to structural subsum entities.
3.2.1 Static Extraction of Relevant Values
To begin with, Listing 2 shows (relevant) instances of domain predicates, evaluated upon grounding, for the CSP from Example 1. While derived facts in Line 1 merely provide a projection of the predicate var/3 omitting associated domains, the instances of look/2 in Line 2 express that all values in the common domain of , , and shall be considered. In fact, domain predicates extract variable values that can be relevant for the satisfiability of a CSP instance, while discarding the rest. The respective static analysis consists of three stages: (i) isolation of threshold values relevant to linear inequalities; (ii) addition of missing values for variables occurring in alldifferent constraints; (iii) addition of white/black list values for table constraints.
In the first stage, we consider the domains of Integer variables in terms of corresponding (nonoverlapping) intervals . These are extended to multiplications by Integer constants according to the following scheme:
For from in (2), we get , , and . Such intervals are used to retrieve bounds for (sub)sums:
Given , , , , , and , we derive , , , and .
In view of the comparison with in , we can now “push in” relevant thresholds via:
Such threshold analysis leads to , , , , and , telling us that subsums relevant for checking whether satisfy and . Note that maxima (or minima) used to construct (or ) serve two purposes. For one, they correct infeasible arithmetical thresholds to domain values; e.g., tells us that would be the greatest lower bound to consider for (since were necessarily satisfied when ), while the smallest possible value exceeds . For another, dominating values like are discarded, given that cannot hold when .
Letting , the upper bounds for that deserve further consideration are then obtained as follows:
Starting from the above thresholds, , , and indicate upper bounds for subsums that are of interest in evaluating . Upper bounds in can in turn be related to “maximal” pairs of addends:
In our example, we get , , and .
Finally, we associate each pair of addends with the upper bound , thus obtaining , , , , , and .
The described analysis of thresholds for subsums is implemented via deterministic domain predicates in our ASP encoding. Variables’ domain values underlying relevant addends are provided by the derived facts in Line 10–12 of Listing 2. Note that value for as well as for are ignored here, given that and do not admit to hold. The mapping of relevant addends to their associated upper bound can be observed in Line 14–20 for the (sub)sums and . The respective facts describe patterns for mapping assigned domain values to their multiplication results and then to upper bounds for subsums, which are eventually subject to a (nontrivial) comparison in some linear inequality. (Trivial comparisons are performed via the total upper bound for an addition result, as given in Line 22.) Notably, the static threshold analysis is implemented on terms representing the domains of variables, and outcomes are then mapped back to original variables. Thus, linear inequalities over different variables with the same domains are analyzed only once. The final function terms, however, mention the variables whose values are evaluated, where recurring substructures may share a common term with which all relevant threshold values are associated.
Although the analysis of the linear inequality identifies the values for and for as redundant, the presence of leads to their “release” as relevant candidates for and . Accordingly, all values in the common domain of , , and are put into (decreasing) order, given by the derived facts in Line 4–5. Beyond that, the order among relevant upper bounds in is reflected in Line 7–8; this is used to apply the order encoding to structural subsum variables (in addition to the input variables , , and ). The residual derived facts in Line 24–31 serve convenience by associating indexes to the arguments of as well as to and considered in . Furthermore, the fact in Line 27 indicates the index of variable in as the final position at which either of the values , , or can possibly be assigned, and the fact in Line 28 expresses that all three values in must be assigned in order to satisfy .
3.2.2 Nondeterministic Encoding Part
With the described domain predicates at hand, the encoding part in Listing 3 implements the nondeterministic guessing of a variable assignment along with the evaluation of constraint clauses. Following the idea of order encodings in SAT [4, 5], the choice rule in Line 3 permits guessing less(V,E) for all but the smallest (relevant) value E in the domain of an Integer variable V, thus indicating that V is assigned to some smaller value than E. The consistency among guessed atoms is established by the integrity constraint in Line 4, requiring less(V,E1) to hold if less(V,E2) is true for the (immediate) predecessor value E2 of E1. The actual value assigned to V, given by the greatest E for which less(V,E) is false, is extracted in Line 5. For Boolean variables, the value true can be guessed unconditionally via the choice rule in Line 7, and false is derived otherwise via the rule in Line 8.
The dedicated extension of the order encoding idea to subsums of linear inequalities is implemented by means of the rules in Line 12–15 of Listing 3. To this end, upper bounds for singular multiplication results indicated as relevant by instances of look(op(mul,F,V),E,G) are directly derived from less/2. Thereby, the flag GFF provides the polarity of the actual coefficient F.^{5}^{5}5Coefficients given in facts generated by aspartame are distinct from . If F is positive, i.e., G1, the upper bound F*E is established as soon as less(V,EE) holds for the immediate successor value EE of E (or if E is the greatest relevant value in the domain of V). On the other hand, if G1 indicates that F is negative, the upper bound F*E is derived from not less(V,E), which means that the value assigned to V is greater than or equal to E. Relevant upper bounds E for subsums rely on maximal pairs E1E2 of addends, identified via static threshold analysis and readily provided by instances of look(op(add,S1,S2),E1,E2,E). In fact, the rule in Line 14 derives leq(op(add,S1,S2),E), indicating that S1S2E, from leq(S1,E1) and leq(S2,E2). Although an established upper bound inherently implies any greater (relevant) upper bound to hold as well w.r.t. a total variable assignment, ASP (and SAT) solvers are not committed to guessing “input variables” first. Rather, structural variables like the instances of leq(op(add,S1,S2),E) may be fixed upon solving, possibly in view of recorded conflict clauses, before a total assignment has been determined. In view of this, the additional rule in Line 15 makes sure that an established upper bound EE propagates to its immediate successor E (if there is any). For instance, (simplified) ground instances of the rule stemming from include the following:
leq(op(add,op(mul,4,x),op(mul,3,y)),1) : 
leq(op(add,op(mul,4,x),op(mul,3,y)),2). 
leq(op(add,op(mul,4,x),op(mul,3,y)),2) : 
leq(op(add,op(mul,4,x),op(mul,3,y)),3). 
Unlike with the domains of Integer variables, we rely on a rule, rather than an integrity constraint, to establish consistency among the bounds for structural subsums. The reason for this is that upper bounds for addends S1 and S2, contributing left and right justifications, may include divergent gaps, so that consistent value orderings for them are, in general, not guaranteed to immediately produce all relevant upper bounds for S1S2. Encoding variants resolving this issue and using integrity constraints like the one in Line 4 are a subject to future investigation.
While linear inequalities can be evaluated by means of boundaries derived more or less directly from instances of less(V,E), the evaluation of alldifferent and table constraints in Line 19–23 and Line 27–30 of Listing 3 relies on particular instances of value(V,E). The basic idea of checking whether an alldifferent constraint holds is to propagate assigned values along the indexes of participating variables. Then, a recurrence is detected when the value assigned to a variable with index I has been marked as already assigned, as determined from seen(A,I1,E) in Line 22. Moreover, whenever difall(A) indicates that all domain values for the variables in argument list A must be assigned, the rule in Line 23 additionally derives a recurrence from some gap (a value that has not been assigned to the variable at the last possible index). Our full encoding further features socalled “pigeonhole constraints” (cf. [10, 11]) to check that the smallest or greatest domain values for an alldifferent constraint with variables are not populated by more than variables for . Such conditions can again be checked based on instances of less(V,E), and both counterbased (cf. [12]) as well as aggregatebased (cf. [13]) implementations are applicable in view of the native support of aggregates by ASP solvers like clasp (cf. [14]
). In fact, the usage of rules to express redundant constraints, like the one in Line 23 or those for pigeonhole constraints, as well as their ASP formulation provide various degrees of freedom, where comprehensive evaluation and configuration methods are subjects to future work.
The strategy for evaluating table constraints is closely related to the one for detecting value recurrences in alldifferent constraints. Based on the indexes of variables in a table constraint, tuples that are (still) admissible are forwarded via the rules in Line 27–28. The inclusion of a full tuple in an assignment is detected by the rule in Line 30, checking whether the arity I of a table constraint has been reached for some tuple, where a value supports or conflicts for U additionally indicates whether the included tuple belongs to a white or black list, respectively. Note that this strategy avoids explicit references to variables whose values are responsible for the exclusion of tuples, given that lack of inclusion is detected from incomplete tuple traversals.
Finally, the rules in Line 34–49 explore the values assigned to Boolean variables and the outcomes of evaluating particular kinds of constraints to derive hold(C) if and only if some positive or negative literal in C is satisfied or unsatisfied, respectively, w.r.t. the variable assignment represented by instances of value(V,E). Without going into details, let us still note that our full encoding also features linear inequalities relying on the comparison operators , , and , for which additional rules are included to derive hold(C), yet sticking to the principle of upper bound evaluation via leq/2. In fact, the general possibility of complemented constraint expressions as well as of disjunctions potentially admits unsatisfied constraint expressions w.r.t. solutions, and our encoding reflects this by separating the evaluation of particular constraint expressions in Line 12–30 from further literal and clause evaluation in Line 34–49.
4 The aspartame System
The architecture of the aspartame system is given in Figure 1. As mentioned, aspartame reuses sugar’s frontend for parsing and normalizing CSPs. Hence, it accepts the same input formats, viz. XCSP^{6}^{6}6http://www.cril.univartois.fr/CPAI08/XCSP2_1.pdf and sugar’s native CSP format^{7}^{7}7http://bach.istc.kobeu.ac.jp/sugar/package/current/docs/syntax.html. We then implemented an output hook for sugar that provides us with the resulting CSP instance in the fact format described in Section 3.1. These facts are then used for grounding the (full version of the) dedicated ASP encoding in Listing 3 or an alternative one (discussed below). This is done by the ASP grounder gringo. In turn, the resulting propositional logic program is passed to the ASP solver clasp that returns an assignment, representing a solution to the original CSP instance.
We empirically access the performance of aspartame relative to two ASP encodings, the dedicated one described in Section 3.2 as well as a more direct encoding inspired by the original CNF construction of sugar [5], and additionally consider the SATbased reference solver sugar (2.0.0). In either case, we use the combined ASP and SAT solver clasp (2.1.0), and ASPbased approaches further rely on gringo (3.0.5) for grounding ASP encodings on facts generated by aspartame. We selected 60 representative CSP instances (that are neither too easy nor too hard), consisting of intensional and global constraints, from the benchmarks of the 2009 CSP Competition^{8}^{8}8http://www.cril.univartois.fr/CPAI09 for running systematic experiments on a cluster of Linux machines equipped with dual Xeon E5520 quadcore 2.26 GHz processors and 48 GB RAM. To get some first insights into suitable search options, we ran clasp
with its default (berkminlike) and the popular “vsids” decision heuristic; while SATbased preprocessing (cf.
[15]) is performed by default on CNF inputs, we optionally enabled it for (ground) ASP instances, leading to four combinations of clasp settings for ASPbased approaches and two for SATbased sugar.ASP Encoding 1 (dedicated)  ASP Encoding 2 (SATinspired)  sugar  
Benchmark  convert  ground  default  vsids  satpre  vsids/  ground  default  vsids  satpre  vsids/  convert  default  vsids 
satpre  satpre  
1fullins55  2.02  1.41  13.96  11.28  5.15  3.66  0.91  10.72  12.15  6.72  7.18  1.73  2.40  2.19 
3fullins56  3.55  32.39  17.07  14.90  21.75  6.52  11.26  13.08  16.52  11.53  14.02  5.36  1.91  1.50 
4fullins47  2.20  4.45  28.35  45.59  22.02  28.38  2.29  20.03  39.92  28.60  42.91  2.80  2.19  4.81 
abb313GPIA7  5.02  46.97  0.67  1.85  0.71  2.01  20.33  31.75  2.27  41.61  1.63  7.18  6.05  0.05 
abb313GPIA8  5.14  51.23  411.17  460.56  521.11  TO  21.97  173.06  451.02  433.31  180.33  7.23  131.41  70.57 
abb313GPIA9  5.96  52.79  TO  TO  TO  TO  24.68  243.72  TO  289.54  TO  8.49  0.59  5.73 
bibd89849421_glb  3.68  28.30  TO  20.70  4.47  1.42  28.59  10.52  18.11  5.36  8.41  11.28  1.65  1.49 
bibd101203638_glb  5.20  69.94  46.68  11.62  8.21  1.13  76.65  15.84  4.55  2.47  7.93  13.63  7.28  0.85 
bibd2525993_glb  7.34  84.68  TO  434.23  3.50  1.13  17.53  235.11  177.27  TO  59.41  8.90  28.86  41.12 
bibd3131661_glb  9.74  254.13  159.32  3.34  156.71  14.64  39.84  12.24  0.18  0.17  0.11  17.39  77.95  0.20 
C2315  0.88  3.30  0.21  0.13  0.15  0.08  9.74  6.03  4.88  6.63  8.24  1.64  7.37  1.05 
C4161  1.44  24.44  4.66  2.86  4.90  2.80  148.33  TO  TO  TO  TO  3.40  3.06  9.87 
C4261  2.96  26.04  6.26  1.98  6.16  2.04  152.33  222.52  69.47  227.54  165.80  3.22  7.05  3.21 
C5391  2.73  71.55  31.42  10.32  31.87  11.91  TO  TO  TO  TO  TO  7.89  261.39  TO 
chnl1011  0.37  0.18  0.64  1.20  4.36  11.44  0.14  1.35  2.65  12.40  13.75  0.92  19.58  55.26 
chnl1015  0.70  0.17  9.15  3.08  6.95  10.61  0.19  4.04  20.14  10.82  18.01  0.51  32.07  24.68 
chnl1020  0.56  0.24  19.14  6.91  6.51  5.22  0.33  41.96  38.34  6.81  11.98  1.11  7.77  6.30 
chnl1015pbcnfcr  0.42  0.42  9.28  3.05  6.93  10.74  0.20  4.00  20.05  10.90  16.43  1.12  31.85  24.87 
costasArray14  0.46  0.82  3.54  2.93  3.65  4.87  0.62  18.63  18.19  24.79  6.52  2.03  0.25  0.07 
costasArray15  0.52  0.94  17.96  60.17  75.50  17.95  0.78  62.10  136.40  4.96  8.83  1.59  18.41  8.16 
costasArray16  0.52  1.20  15.13  30.18  69.69  0.99  1.03  130.75  203.94  245.02  36.31  1.71  32.65  33.25 
costasArray17  0.56  1.50  TO  TO  TO  232.64  1.28  TO  TO  TO  TO  2.08  148.55  553.54 
fischer12fair  1.44  304.21  11.21  92.81  11.42  18.79  28.50  23.81  7.81  TO  TO  3.42  0.97  0.02 
fischer23fair  4.18  348.84  0.85  21.11  0.79  6.50  68.42  23.19  3.69  23.71  3.54  7.19  0.13  0.04 
fischer38fair  30.18  515.69  TO  458.58  TO  60.32  376.33  TO  TO  TO  TO  35.16  22.05  37.27 
fischer46fair  35.12  535.93  282.84  242.05  386.37  274.27  384.19  TO  TO  TO  TO  39.15  17.16  8.79 
fischer61fair  4.40  457.55  0.91  12.16  0.90  14.68  150.78  TO  10.29  TO  5.46  13.20  1.79  2.69 
magicSquare6_glb  0.29  2.72  46.20  1.23  4.27  1.49  4.20  9.50  2.42  18.39  1.77  2.26  0.79  0.46 
magicSquare7_glb  0.28  8.04  7.54  78.17  1.15  30.18  15.63  51.08  9.59  51.00  7.41  3.00  4.10  2.20 
magicSquare8_glb  0.42  21.75  TO  318.69  477.11  47.22  53.61  331.09  19.14  124.79  36.60  6.29  5.50  3.72 
mpsmzzv42z  4.84  166.01  2.74  1.54  2.61  1.02  395.20  8.56  5.44  8.75  5.20  24.84  5.44  3.28 
mpsp2756  1.74  278.02  4.98  11.89  5.04  5.29  TO  TO  TO  TO  TO  161.39  1.32  1.20 
mpsredair06  11.59  272.57  139.86  381.61  34.78  25.27  TO  TO  TO  TO  TO  27.73  0.63  TO 
mpsredfiber  1.28  92.78  5.07  3.78  5.34  5.39  388.43  33.55  TO  33.43  TO  38.74  2.05  6.76 
queensKnights505add  1.81  16.86  18.62  24.71  44.44  18.79  28.12  558.69  85.48  537.34  44.58  3.25  12.15  0.66 
queensKnights505mul  3.50  17.31  40.78  48.54  38.57  20.64  30.33  221.08  67.39  TO  50.76  3.29  2.10  0.63 
queensKnights805mul  2.47  77.52  181.70  354.74  172.33  383.73  126.32  TO  426.53  TO  414.97  5.81  7.61  2.51 
queensKnights1005add  3.49  163.50  TO  TO  TO  TO  243.06  TO  TO  TO  TO  6.92  18.45  4.39 
ramsey163  1.07  0.51  1.17  1.16  0.18  0.10  0.39  6.74  0.53  0.78  1.04  2.19  1.99  112.63 
ramsey304  2.13  5.91  150.64  180.79  28.56  26.47  2.75  198.83  98.97  82.69  32.39  2.35  8.09  8.67 
ramsey334  2.53  7.58  405.05  279.25  93.36  66.78  4.05  TO  193.49  173.67  109.45  3.13  32.02  39.82 
ramsey344  2.34  8.46  TO  TO  366.41  109.45  4.14  TO  TO  TO  317.08  2.78  67.41  38.71 
ruler349a4  1.15  13.01  21.70  29.62  19.05  19.16  3.08  35.29  39.71  38.59  39.19  4.30  41.98  41.16 
ruler4410a4  1.56  37.60  367.84  233.65  302.54  280.79  8.39  567.20  542.78  TO  483.85  9.91  405.96  446.66 
ruler449a4  1.04  23.41  182.48  124.14  172.79  118.37  6.18  351.14  13.41  102.36  34.25  6.61  TO  352.28 
ruler5510a3  1.08  5.89  TO  500.84  TO  TO  3.19  TO  TO  TO  TO  1.73  43.23  70.22 
superjobShope0ddr18  1.21  6.42  555.34  19.21  14.32  3.67  3.66  6.10  0.11  6.92  1.05  1.16  1.21  0.49 
superjobShope0ddr21  1.08  7.59  TO  32.94  8.38  12.14  3.81  16.08  0.84  2.56  3.87  1.51  5.41  0.76 
superjobShopenddr23  1.00  8.60  TO  116.06  76.55  12.93  3.95  13.21  2.59  5.30  6.33  2.15  1.19  0.72 
superostaillard74  1.02  35.84  TO  493.02  TO  454.02  15.35  36.02  36.35  35.06  32.14  2.08  1.14  0.89 
superostaillard76  1.01  35.51  115.70  TO  112.53  TO  14.49  169.99  30.25  144.26  25.89  2.14  4.20  0.76 
superostaillard77  0.84  32.73  155.31  270.49  132.71  311.67  13.53  23.55  17.77  25.74  15.78  1.95  0.80  0.78 
superostaillard78  0.95  33.23  431.15  279.09  475.51  328.50  14.46  46.95  25.64  40.83  24.06  2.01  1.19  0.96 
zeroini110  1.97  2.41  20.92  27.16  14.97  16.18  1.74  22.09  28.81  26.62  18.56  2.17  3.48  2.57 
zeroini310  1.76  1.92  7.24  33.14  11.43  16.93  1.52  13.45  29.43  19.72  31.67  2.22  4.57  4.11 
ii32c4  3.73  21.92  0.24  0.02  0.03  0.03  56.69  0.02  0.01  0.03  0.04  21.67  8.77  0.76 
ii32d3  2.80  11.87  4.58  13.70  0.39  0.26  25.12  3.54  0.31  0.54  1.35  12.33  71.17  0.20 
p2756  2.06  269.82  3.87  12.55  3.99  6.13  TO  TO  TO  TO  TO  162.72  4.26  2.41 
oooburchdill3acclucl  2.46  14.06  13.80  18.60  6.13  5.95  5.82  30.05  24.18  12.73  4.61  2.77  1.28  1.00 
oootag14  6.93  191.71  145.03  144.09  158.56  158.99  44.99  109.54  310.78  20.82  25.11  10.67  6.54  6.07 
Average Time  3.51  80.21  188.67  149.80  129.06  103.87  91.49  209.46  184.50  218.43  169.76  12.56  37.47  54.27 
Timeouts  0  0  12  5  6  5  4  14  13  17  13  0  1  2 
Table 1 reports runtime results in seconds, separated into conversion time of aspartame from CSP instances to ASP facts (first “convert” column) and of sugar from CSP instances to CNF, gringo times for grounding ASP encodings relative to facts, and finally columns for the search times of clasp with the aforementioned options. Each computational phase was restricted to 600 seconds, and timeouts counted in the last row of Table 1 are taken as 600 seconds in the second last row providing average runtimes. Looking at these summary rows, we observe that our two ASP encodings are solved most effectively when vsids decision heuristic and SAT preprocessing are both enabled; unlike this, neither decision heuristic dominates the other on CNF input. Apparently, clasp on CNFs generated by sugar still has a significant edge on facts by aspartame combined with either ASP encoding. In particular, we observe drastic performance discrepancies on some instance families (especially “fischer” and “queensKnights”), where clasp performs stable on CNFs from sugar but runs into trouble on corresponding ASP instances. Given that aspartame and its ASP encodings are prototypes, such behavior does not disprove the basic approach, but rather motivates future investigations of the reasons for performance discrepancies. For one, we conjecture that normalizations of global constraints that are not yet supported by aspartame are primarily responsible for large instance sizes and long search times on some instance families. For another, we suppose that both of our ASP encodings are still quite naive compared to years of expertise manifested in sugar’s CNF construction. However, the observation that our dedicated ASP encoding has on edge the SATinspired one and yields significant performance improvements on some instance families (“C2315”–“C5391” and “mps”) clearly encourages further investigations into ASP encodings of CSP instances.
5 Related Work
Unlike approaches to constraint answer set solving, e.g., [10, 16, 17, 18], which aim at integrating CSP and ASP solving (engines), the focus of aspartame lies on pure CSP solving. In fact, aspartame’s approach can be regarded as a firstorder alternative to SATbased systems like sugar [5], where the performance of the underlying SAT solver is crucial. However, it is now becoming recognized that the SAT encoding to be used also plays an important role [19]. There have been several proposals of encoding constraints to SAT: direct encoding [20, 21], support encoding [22, 23], log encoding [24, 25], log support encoding [26], regular encoding [27], order encoding [4, 5], and compact order encoding [28].
The order encoding, where Boolean variables represent whether holds for variables and values , showed good performance for a wide range of CSPs [4, 11, 27, 29, 30, 31, 32, 33, 34]. Especially, the SATbased constraint solver sugar became a winner in global constraint categories at the 2008 and 2009 CSP solver competitions [35]. Moreover, the SATbased CSP solver BEE [36] and the CLP system BProlog [37] utilize the order encoding. In fact, the order encoding provides a compact translation of arithmetic constraints, while also maintaining bounds consistency by unit propagation. Interestingly, it has been shown that the order encoding is the only existing SAT encoding that can reduce tractable CSP to tractable SAT [38].
6 Conclusion
We presented an alternative approach to solving finite linear CSPs based on ASP. The resulting system aspartame relies on highlevel ASP encodings and delegates both the grounding and solving tasks to generalpurpose ASP systems. We have contrasted aspartame with its SATbased ancestor sugar, which delegates only the solving task to offtheshelf SAT solvers, while using dedicated algorithms for constraint preprocessing. Although aspartame does not fully match the performance of sugar from a global perspective, the picture is fragmented and leaves room for further improvements. This is to say that different performances are observed on distinct classes of CSPs, comprising different types of constraints. Thus, it is an interesting topic of future research to devise more appropriate ASP encodings for such settings. Despite all this, aspartame demonstrates that ASP’s generalpurpose technology allows to compete with stateoftheart constraint solving techniques, not to mention that aspartame’s intelligence is driven by an ASP encoding of less than 100 code lines (for nondeterministic predicates subject to search). In fact, the highlevel approach of ASP facilitates extensions and variations of firstorder encodings for dealing with particular types of constraints. In the future, we thus aim at more exhaustive investigations of encoding variants, e.g., regarding alldifferent constraints, as well as support for additional kinds of global constraints.
Acknowledgments
This work was partially funded by the Japan Society for the Promotion of Science (JSPS) under grant KAKENHI 24300007 as well as the German Science Foundation (DFG) under grant SCHA 550/83 and SCHA 550/91. We are grateful to the anonymous reviewers for many helpful comments.
References
 [1] Dechter, R.: Constraint Processing. Morgan Kaufmann Publishers (2003)
 [2] Rossi, F., van Beek, P., Walsh, T., eds.: Handbook of Constraint Programming. Elsevier Science (2006)
 [3] Biere, A., Heule, M., van Maaren, H., Walsh, T., eds.: Handbook of Satisfiability. IOS Press (2009)

[4]
Crawford, J., Baker, A.:
Experimental results on the application of satisfiability algorithms
to scheduling problems.
In HayesRoth, B., and Korf, R., eds.: Proceedings of the Twelfth National Conference on Artificial Intelligence (AAAI’94), AAAI Press (1994) 1092–1097
 [5] Tamura, N., Taga, A., Kitagawa, S., Banbara, M.: Compiling finite linear CSP into SAT. Constraints 14(2) (2009) 254–272
 [6] Baral, C.: Knowledge Representation, Reasoning and Declarative Problem Solving. Cambridge University Press (2003)
 [7] Gebser, M., Kaminski, R., Kaufmann, B., Schaub, T.: Answer Set Solving in Practice. Morgan and Claypool Publishers (2012)
 [8] Gebser, M., Kaminski, R., Kaufmann, B., Ostrowski, M., Schaub, T., Thiele, S.: A user’s guide to gringo, clasp, clingo, and iclingo.^{9}^{9}9http://potassco.sourceforge.net
 [9] Beldiceanu, N., Simonis, H.: A constraint seeker: Finding and ranking global constraints from examples. In Lee, J., ed.: Proceedings of the Seventeenth International Conference on Principles and Practice of Constraint Programming (CP’11), SpringerVerlag (2011) 12–26
 [10] Drescher, C., Walsh, T.: A translational approach to constraint answer set solving. Theory and Practice of Logic Programming 10(46) (2010) 465–480
 [11] Metodi, A., Codish, M., Stuckey, P.: Boolean equipropagation for concise and efficient SAT encodings of combinatorial problems. Journal of Artificial Intelligence Research 46 (2013) 303–341
 [12] Sinz, C.: Towards an optimal CNF encoding of Boolean cardinality constraints. In van Beek, P., ed.: Proceedings of the Eleventh International Conference on Principles and Practice of Constraint Programming (CP’05), SpringerVerlag (2005) 827–831
 [13] Simons, P., Niemelä, I., Soininen, T.: Extending and implementing the stable model semantics. Artificial Intelligence 138(12) (2002) 181–234
 [14] Gebser, M., Kaminski, R., Kaufmann, B., Schaub, T.: On the implementation of weight constraint rules in conflictdriven ASP solvers. [39] 250–264
 [15] Eén, N., Biere, A.: Effective preprocessing in SAT through variable and clause elimination. In Bacchus, F., Walsh, T., eds.: Proceedings of the Eighth International Conference on Theory and Applications of Satisfiability Testing (SAT’05), SpringerVerlag (2005) 61–75
 [16] Gebser, M., Ostrowski, M., Schaub, T.: Constraint answer set solving. [39] 235–249
 [17] Balduccini, M.: Representing constraint satisfaction problems in answer set programming. In Faber, W., Lee, J., eds.: Proceedings of the Second Workshop on Answer Set Programming and Other Computing Paradigms (ASPOCP’09), (2009) 16–30
 [18] Ostrowski, M., Schaub, T.: ASP modulo CSP: The clingcon system. Theory and Practice of Logic Programming 12(45) (2012) 485–503
 [19] Prestwich, S.: CNF encodings. [3] 75–97
 [20] de Kleer, J.: A comparison of ATMS and CSP techniques. In Sridharan, N., ed.: Proceedings of the Eleventh International Joint Conference on Artificial Intelligence (IJCAI’89), Morgan Kaufmann Publishers (1989) 290–296
 [21] Walsh, T.: SAT v CSP. In Dechter, R., ed.: Proceedings of the Sixth International Conference on Principles and Practice of Constraint Programming (CP’00), SpringerVerlag (2000) 441–456
 [22] Kasif, S.: On the parallel complexity of discrete relaxation in constraint satisfaction networks. Artificial Intelligence 45(3) (1990) 275–286
 [23] Gent, I.: Arc consistency in SAT. In van Harmelen, F., ed.: Proceedings of the Fifteenth European Conference on Artificial Intelligence (ECAI’02), IOS Press (2002) 121–125
 [24] Iwama, K., Miyazaki, S.: SATvariable complexity of hard combinatorial problems. In Pehrson, B., Simon, I., eds.: Proceedings of the Thirteenth IFIP World Computer Congress (WCC’94), NorthHolland (1994) 253–258
 [25] Van Gelder, A.: Another look at graph coloring via propositional satisfiability. Discrete Applied Mathematics 156(2) (2008) 230–243
 [26] Gavanelli, M.: The logsupport encoding of CSP into SAT. In Bessiere, C., ed.: Proceedings of the Thirteenth International Conference on Principles and Practice of Constraint Programming (CP’07), SpringerVerlag (2007) 815–822
 [27] Ansótegui, C., Manyà, F.: Mapping problems with finitedomain variables into problems with Boolean variables. In Hoos, H., Mitchell, D., eds.: Proceedings of the Seventh International Conference on Theory and Applications of Satisfiability Testing (SAT’04), SpringerVerlag (2004) 1–15
 [28] Tanjo, T., Tamura, N., Banbara, M.: Azucar: A SATbased CSP solver using compact order encoding (tool presentation). In Cimatti, A., Sebastiani, R., eds.: Proceedings of the Fifteenth International Conference on Theory and Applications of Satisfiability Testing (SAT’12), SpringerVerlag (2012) 456–462
 [29] Bailleux, O., Boufkhad, Y.: Efficient CNF encoding of Boolean cardinality constraints. In Rossi, F., ed.: Proceedings of the Ninth International Conference on Principles and Practice of Constraint Programming (CP’03), SpringerVerlag (2003) 108–122
 [30] Gent, I., Nightingale, P.: A new encoding of AllDifferent into SAT. In Frisch, A., Miguel, I., eds.: Proceedings of the Third International Workshop on Modelling and Reformulating Constraint Satisfaction Problems (ModRef’04), (2004) 95–110
 [31] Inoue, K., Soh, T., Ueda, S., Sasaura, Y., Banbara, M., Tamura, N.: A competitive and cooperative approach to propositional satisfiability. Discrete Applied Mathematics 154(16) (2006) 2291–2306
 [32] Soh, T., Inoue, K., Tamura, N., Banbara, M., Nabeshima, H.: A SATbased method for solving the twodimensional strip packing problem. Fundamenta Informaticae 102(34) (2010) 467–487
 [33] Ohrimenko, O., Stuckey, P., Codish, M.: Propagation via lazy clause generation. Constraints 14(3) (2009) 357–391
 [34] Banbara, M., Matsunaka, H., Tamura, N., Inoue, K.: Generating combinatorial test cases by efficient SAT encodings suitable for CDCL SAT solvers. In Fermüller, C., Voronkov, A., eds.: Proceedings of the Seventeenth International Conference on Logic for Programming, Artificial Intelligence, and Reasoning (LPAR’10), SpringerVerlag (2010) 112–126
 [35] Lecoutre, C., Roussel, O., van Dongen, M.: Promoting robust blackbox solvers through competitions. Constraints 15(3) (2010) 317–326
 [36] Metodi, A., Codish, M.: Compiling finite domain constraints to SAT with BEE. Theory and Practice of Logic Programming 12(45) (2012) 465–483
 [37] Zhou, N.: The SAT compiler in Bprolog. The Association for Logic Programming Newsletter, March 2013 (2013)^{10}^{10}10http://www.cs.nmsu.edu/ALP/2013/03/thesatcompilerinbprolog
 [38] Petke, J., Jeavons, P.: The order encoding: From tractable CSP to tractable SAT. In Sakallah, K., Simon, L., eds.: Proceedings of the Fourteenth International Conference on Theory and Applications of Satisfiability Testing (SAT’11), SpringerVerlag (2011) 371–372
 [39] Hill, P., Warren, D., eds.: Proceedings of the Twentyfifth International Conference on Logic Programming (ICLP’09), SpringerVerlag (2009)
Comments
There are no comments yet.