I Introduction
Constraint Programming (CP) is a powerful declarative programming paradigm where traditional instructions are replaced with relations over variables. CP has shown for a long term its ability to model and solve many hard combinatorial problems. This is due to the fact, that CP supports several types of relations between values and constraints, including arithmetical, numerical, logical, and symbolic constraints, as well as various computational domains, such as integers, reals, lists, strings, trees, graphs, etc. By considering a large variety of realworld problems, spanning from car manufacturing, configuration design to energy production and hardware and software engineering, CP is a crucial paradigm for exact solving of constraint systems, which has been proven in many practical applications.
However, unlike SATsolving, CP has traditionally only considered conjunction of
constraints. Even though powerful reasoning capabilities are
available in CP, disjunctions have to be handled by the user, which has to find
ways to model disjunctions using the available modeling tools and global constraints.
In CP, the
constraint system is a set of constraints implicitly combined via conjunction.
Dealing with disjunctions in CP has always been perceived as challenging. This
is due to the uneasy tradeoff between search and inference while searching for
satisfying assignments. Indeed, despite the usual exploitation of hypothesis
refutation in the search process, inference has traditionally been mostly
considered for conjunction of constraints. Notable exceptions include the
definition of few global constraints, which embed disjunctive reasoning, such as
cumulative [1] or element [10]. To illustrate
the usual absence of inference for disjunctive constraints, consider the following
request to SICStus Prolog clp(FD)[4], a stateoftheart CP solver over Finite Domains:
Example 1
Query: (X#=1) #\/ (X#=3) #\/ (X in 6..7)
Answer: X in inf..sup
//
’logical or’ in clpfd
In this example, as no information is available on X, the solver
uses only local reasoning for each disjunct and thus
cannot perform any pruning. As a consequence, the domain of X is left unconstrained.
Of course, for this request, an obvious and stronger answer would be the following:
Example 2
Q: (X#=1) cd (X#=3) cd (X in 6..7)
A: X in{1}\/{3}\/(6..7)
//cd
means ’constr. disj.’
Getting this result requires to use some global reasoning through a constructive disjunction operator,
that is an operator able to construct knowledge
from both disjuncts, without knowing which one will be true.
In most CP implementations, the ’constructive disjunction’ operator is unfortunately
not natively available, as it is considered as too costly to propagate.
Note that, besides the simple example given above, a complete implementation has to consider much more complex
constraints in the disjuncts such as shown in the following example.
Example 3
Q: A,B in 1..10, (A#>1,B#<9)cd(A#>2,A#<10),
(A+7#=<B) cd ( cn(B+7#>A) )
// cn
means ’constructive negation.’
A: A in{3}\/(8..10), B in(1..3)\/{10}
Constructive reasoning requires to perform a deep analysis of each disjunct before any constructive information
can be propagated through the constraint network.
Such constructive knowledge can be useful to solve efficiently many practical realworld
problems originating from planning [6], scheduling [15],
software engineering [5] or configuration.
In many cases, realworld systems are highly configurable and
each configuration can lead to a slightly different constraint system.
Constructive disjunction is not new in CP. Besides the initial proposition by Van Hentenryck [10], several implementations have been proposed in different CSP solvers including Oz [22], Gecode [19], SICStus Prolog [2] or Choco4 [17]. Implementation of constructive disjunction propagators in CP solvers is usually considered straightforward when it is perceived as an extension of constraint reification [11]. In that case, it suffices to associate a Boolean variable to any constraint, representing its truth value, and use Boolean constraints to combine the constraints. This approach is available in Choco4, for example, with its embedded SAT solver. In SICStus Prolog clp(FD), besides the constraint reification mechanism, a more sophisticated approach is available through the smt global constraint [2] which propagates disjunctive linear information. Reasoning over disjunctions of temporal constraints has also been extensively considered in CP, with specialized algorithms [21].
The problem with the reification approach is that it propagates little constructive information. Entailment is usually poorly deductive as it is limited to local reasoning, that is, local filtering over the variables of the reified constraint. In most cases, more constructive knowledge can be propagated but the implementation of constructive disjunction requires a good tradeof between inference and search. An interesting attempt in that direction is given in [20, 16] where interval reasoning is used to propagate more information through constraint refutation. The proposed approach is however limited to numerical constraint systems and does not easily extend to finite domains constraints.
In this paper, we propose a lightweight approach to constructive disjunction which can be implemented on top of any existing CP solver, whatever be the level of filtering consistency considered and the constraint language in usage. We propose a parametric stratified reasoning to cope with the inherent combinatorial explosion of disjunctive problems. Our opensource and openaccess implementation on top of the SICStus Prolog, called If Then Else (ITE)^{1}^{1}1Available at https://github.com/ite4cp/ite, makes use of the global constraint definition mechanism of clp(FD). We argue that the availability of alternative ways to deal with disjunctive problems in CP is crucial to its adoption for solving realworld industrial problems, e.g., test case generation for specific domains [8] or generation of equiprobable test data [9].
The rest of this paper is organized as follows. Section II introduces the necessary background and notations to understand the rest of the paper. Section III presents constructive disjunction and negation and discusses of their implementation. This section also presents the various implementations of relaxation of entailments. It contains several examples to help the reader understand the proposed approach. Section IV proposes stratified reasoning to cope with possible combinatorial explosion. Section V gives our experimental results with ITE, while Section VI concludes this work and proposes further work.
Ii Background
Iia Constraint Satisfaction Problems
Constraint Satisfaction Problems (CSP) are materialized by where stands for a set of variables, each variable taking a value into a finite domain and, is a set of constraints. A constraint of arity , is a relation over a subset of variables from which restrains the acceptable tuples for the relation. The subset of variables involved into the relation is usually known in advance, but there are cases where the size of the subset is parameterized by the problem instance. In the former case, the relations are called primary constraints while they are called global constraints in the latter. is said to be satisfied by an assignment of its variables to values from their domain iff evaluates to true with this assignment. A CSP is said to be satisfiable iff there exists at least one full assignment (i.e., an assignment of all variables in also called a solution) such that all constraints in are satisfied with this assignment. Otherwise, the CSP is said to be unsatisfiable. Note that, in this definition, the constraints of are interpreted as a conjunction of constraints.
Solving a CSP means to either exhibit a solution or to prove unsatisfiability. In both cases,
local filtering consistencies are used to approach this question.
Among the many filtering consistencies proposed in the literature, we will focus only on two wellknown,
namely hyperarcconsistency and boundconsistency.
Definition 1
(hyperarcconsistency)
For a given CSP , a constraint is hyperarcconsistent
if for each of its variable
and value there exist values
in such that is satisfied.
A CSP is hyperarcconsistent if for each of its constraints , is hyperarc–consistent.
Filtering a CSP with hyperarcconsistency can be very demanding in terms of computational resources.
That is why other consistencies, less demanding,
have been introduced. Among them, boundconsistency is a good compromise.
Definition 2
(boundconsistency)
A constraint is boundconsistent if for each variable and value
there exist values in
such that is satisfied. In this definition, stands for (obviously ).
A CSP is boundconsistent if for every constraint , is boundconsistent.
IiB Global Constraint Definition
As said above, global constraints are relations over an unknown subset of variables. Typical examples include the all_different constraints which constrains all variables to take different values (here, is a userdefined parameter) or the element which constrains to be equal to . An important feature of modern CSP solvers is their ability to let the user define its own global constraints.
Defining a global constraint requires three elements to be given by the user:

(Interface) An interface has to be defined for the global constraint. This interface contains a name for the constraint along with a list of variables, possibly unbounded ;

(Algorithm) Each time the defined global constraint is considered in the propagation queue of the CSP solver, a filtering algorithm has to be launched with the goal to eliminate as much as possible inconsistent values of variables from their domain ;

(Awakening) Guidance to the awakening of the constraint in the propagation queue must also be provided. It is important to decide when to launch the filtering algorithm in order to avoid any misusage of the constraints. Typical examples of awakening conditions include the change of boundaries of variable domains involved into the relation or the assignment of one of its variables.
For example, SICStus Prolog clp(FD)allows the users to define new global constraints through an interface composed of two distinct parts:

dispatch_global(Constraint, S0, S, Actions)
This predicate tells the solver that the predicateConstraint
is a new global constraint.Constraint
defines the interface of the constraint, whileActions
define what actions to take. These actions include conditions when global inconsistency is proved (i.e., failing condition), when constraint entailment is proved (i.e., success), and partial satisfaction is obtained through variable binding or domain reduction. verb+S0, S+ are used to memorize previous and current states of the variable domains while applying the filtering algorithm ; 
fd_global(Constraint, State, Suspensions)
This predicate is used to post an instance of the constraintConstraint
.Suspensions
define the awakening conditions which include, in this implementation, variable binding, boundaries reduction or domain reduction.State
contains the current state of the variables domain.
Using this mechanism, it is thus possible to implement various types of constraints, including those which are used to combine constraints with logical operators.
IiC Syntax of the Constraint Language
The syntax of ITE constraint language is detailed in Fig. 1.
The language contains several operators working on classical arithmetic constraints. It also introduces logical operators such as which are typically useful to represent logical constraints. Note that the language introduces two version of constructive negation and constructive disjunction in order to distinguish the versions of these operators which implement stratified reasoning from the others. Both logical implication and if_then_else operators only use stratified reasoning as it is more useful (See Sec.IV for more details). This language is powerful as it allows us to perform various form of disjunctive reasoning.
Iii Constructive Operators
Implementing metaconstraints such as disjunction, negation, implication, etc. requires to reason on the truth value of
constraints and their possible (dis)entailment by the current status of the CSP [3].
Definition 3
A constraint is entailed by a CSP iff, for any solution of , the constraint is satisfied.
Note that, by construction, all constraints of are entailed by the CSP . In the
above definition, is not necessary part of .
Example 4
If all tuples of are solutions of a CSP then the constraint
is entailed by .
Proving constraint entailment or disentailment is as demanding as finding all solutions of a CSP. As solving CSP is NP_hard in the general case [10], relaxations of constraint entailment have been proposed.
Iiia Relaxations of Constraint Entailment
Entailment checking in practical settings is based on local filtering consistencies.
Two partial entailment tests have been introduced in [10]:
domainentailment and intervalentailment which are based respectively
on hyperarcconsistency and boundconsistency (See Sec.II).
Another partial entailment test can be introduced here based on constraint refutation, namely Absentailment.
Absentailment is a relaxation of
entailment which exploits the filtering capabilities of the entire CSP to try to refute the negation of the constraint.
Using more formal presentation, we now describe these three
relaxations of entailment which are available in ITE.
Definition 4
(domainentailment)
Let be a CSP having as domains for its variables , then
a constraint is domainentailed by iff,
for all domains and all values
, is satisfied.
Based on this definition, a constraint can be entailed,
but not necessary domainentailed by a CSP . On the contrary, the opposite is true:
any constraint which is domainentailed is also entailed by .
Example 5
If , and then the constraint is entailed but not domainentailed.
In this example, is entailed because all satisfying tuples of , namely are also solutions of . However, this constraint is not domainentailed because there exist pairs in which do not satisfy , e.g., the pair .
Domainentailment is a local property as it requires only to examine the tuples of with respect to
the current domains of its variables. At the same time, proving domainentailment is demanding as it requires
to examine all satisfying tuples of , which can be timeconsuming when domains are huge.
Another lessdemanding relaxation is thus proposed in some solver implementations.
Definition 5
(intervalentailment)
A constraint is intervalentailed by a CSP
iff, for all domains and all
values in , is satisfied.
Obviously, if a constraint is intervalentailed by a CSP , then is also domainentailed as . But, the opposite is not true. Nevertheless, these two relaxed versions of entailment are quite similar and both are used in implementations of classical (non constructive) negation and disjunction. For instance, both are used in SICStus Prolog clp(FD)for implementing the reification operator. This operator is used to evaluate the truth value of any constraint, including some global constraints [2].
IiiB Absentailment
We introduce here another partial entailment test which is based on constraint refutation :
Definition 6
(absentailment)
A constraint is absentailed by a CSP iff
filtering by hyperarcconsistency or boundconsistency the CSP
yields to an inconsistency.
This definition is operational as it is based on concrete filtering properties that are available in most CSP solvers.
As hyperarcconsistency and boundconsistency
are sound relaxations of consistency, it is trivial to see that absentailment is a sound relaxation of entailment. Indeed,
if is inconsistent then and then is entailed.
Unlike domainentailment or intervalentailment,
absentailment is not a local property, restricted to the constraint . It involves all the constraints of the
CSP and requires the computation of . In addition, it requires the restoration of the computational state after the
test of inconsistency of .
Nevertheless absentailment is powerful to deduce entailment and prune domains, more powerful
than domain and/or intervalentailment
as shown in our experiments, given in Sec.V.
IiiC Constructive Disjunction
Absentailment can be used to implement constructive disjunction. By using the global constraint definition mechanism of
a CSP solver, it becomes possible to introduce a new disjunctive constraint, i.e., , where one test whether and
are entailed or not. By adding (resp. ) to the constraint store and checking whether the resulting constraint
system is inconsistent,
one gets an easy absentailment test of (resp. ). Those tests can be performed each time the global constraint is
awakened. Besides, while making these tests, one can register the domains status of each disjunct, after the filtering steps. Having
filtered both and and stored domain information, it becomes possible to construct unified information for the
variable domain of the constructive disjunction constraint. In order to illustrate this principle, an implementation of constructive
disjunction is given in Figure 2. For readers who are familiar with Prolog, the implementation is straightforward. For the other
readers, the interesting part of the implementation lies in the line with comment %(C /\ C1)=>fail ?
.
The corresponding Prolog code exploits the ’negationasfailure’ operator of Prolog to test whether fails or not.
By posting and checking
the failure of the resulting computational state (by constraint propagation), we test if is entailed. If the goal succeeds
then the computation backtracks and undoes what has been deduced from adding .
A typical example of using this implementation is given in the following example.
Example 6
A,B,C in 1..5
Q: (AB#=4)cd(BA#=4), (AC#=4)cd(CA#=4)
A: A,B,C in {1}\/{5}
This implementation raises the question of what to do when, during the inconsistency checks, other such tests have to be performed. This can happen, for example, in the presence of other cd constraints. The implementation given in Figure 2 will just recursively consider all such tests. This deep analysis may lead to a very precise result but, at the same time, will be computationally expensive. For this reason, we introduce in this paper stratified reasoning as a way to cope with this problem. Details are given in Sec.IV, but, let’s examine first the other logical operators constructed using the very same principle.
IiiD Constructive Negation
Typical negation operators in Logic Programming implements negationasfailure, which triggers failure when the negated goal succeeds and conversely. Although very useful in many contexts, this operator coincides with logical negation only when the negated goal is grounded, which means that all its variables are binded. Of course, when negating a constraint, there are several unbounded variables and then posting the negation of a constraint becomes problematic. Constructive negation in Constraint Logic Programming has been proposed to cope with this issue, using Clarke’s completion process
[7]. For CSP, only a few implementations have been considered. In ITE, we propose an implementation which is closed to constructive disjunction, by checking the inconsistency of the negated constraint. Using simple rewriting rules, negated compound constraints can be transformed into conjunction or disjunction of negated simpler constraints, as shown in Figure 3. Interestingly, the constructive negation operation is implemented using the global constraint interface of SICStus, so that, finegrained domain pruning and suspension can be implemented.IiiE Other Operators
Other logical operators based on similar principles can be implemented.
In particular, exclusive disjunction, general constraint
implication operator and conditional are easy to derive from the implementation of constructive disjunction.
For exclusive disjunction C1 cxd C2
, when one disjunct is shown to be inconsistent (e.g., C1
),
one can propagate the negation of this disjunct togather with the other disjunction (call((cn(C1),C2))
), while
this is not possible with nonexclusive disjunction.
Note that conditional reasoning, i.e., if() then else can trivially be converted
into an exclusive disjunction operator by using the formulae: .
As CSP usually work on finite domains,
the closed world hypothesis guarantees that there is no answer available where both and can be true. The following
example illustrates the usage of ite when combined with other constraints.
Example 7
Q:ite(I0#=<16, J2#=J0*I0, J2#=J0, ENV),
J2#>8, J0#=2
A: J0 = 2, I0 in 5..16, J2 in 10..32
Note that other iteoperators can be used in branches of the operators, enabling cascade conditionals.
Iv Stratified Reasoning
In the previous section, we have proposed implementations of logical operators without paying attention to the computational costs of propagating constraints. Even though filtering by hyperarcconsistency and boundconsistency is timepolynomial in the worst case, the number of inconsistency checks performed can rapidly explode and leads to some unwanted combinatorial explosion.
In order to
cope with this problem, we propose stratified reasoning. By setting up a userdefined parameter to a positive integer
(usually a small value), one can decrease by one each time an inconsistency check is performed.
When reaches the value , then the inconsistency
check is simply discarded, avoiding so to perform an uncontrolled and redundant exploration of all disjunctions. A straightforward
implementation of this idea is shown in Figure 4. In this implementation, the variable ENV
captures general
information about the computation, including the value of . While performing the inconsistency check (line with
%K1,C/\C1 => fail?
),
is decreased. When , Actions=[]
which corresponds to the suspension of any reasoning.
This way of handling disjunctive reasoning is correct and does not compromise the final result of CSP solving: it just reports to the final labeling stage the selection of a disjunction. Stratified reasoning is a good tradeoff between search and inference, although coupled with a decision to which aspect is more important.
The following example illustrates the benefice of stratified reasoning. By setting up different values of the
userdefined parameter , one gets distinct results with the same constraint system.
Note that when the parameter is less than the number of cdoperators (in the third case of the example), no deduction is obtained.
We conjecture that should always be setup
to larger value than the number of disjunctive operators in the formulae but we do not
have any formal proof of this. This conjecture
is evaluated in the experimental evaluation section.
Example 8
Q:init_env(E,7),cd(cd(X#=0,Y#=4,E),X#=9,E),
cd(cd(Y#=9,Y#=6,E),Y#=7,E)
A: X in{0}\/{9}, Y in(6..7)\/{9}
Q:init_env(E,6),cd(cd(X#=0,Y#=4,E),X#=9,E),
cd(cd(Y#=9,Y#=6,E),Y#=7,E)
A: X in inf..sup, Y in 6..9
Q:init_env(E,3),cd(cd(X#=0,Y#=4,E),X#=9,E),
cd(cd(Y#=9,Y#=6,E),Y#=7,E)
A: X in inf..sup, Y in inf..sup
V Experimental Results
To confirm the effectiveness of the lightweight approach to constructive disjunction, we compare our ITE implementation to the corresponding standard methods contained in SICStus Prolog clp(FD). We consider representative expressions containing one or multiple constructive operators, including examples from [22] and [14]. The benchmark dataset and its execution scripts are available as part of the ITE distribution^{2}^{2}2Available at https://github.com/ite4cp/ite. All experiments have been conducted with SICStus Prolog version 4.4.1 running on commodity hardware.
The evaluation goal is to identify scenarios that benefit from using ITE over
the standard methods. For this goal, we compare the stratified and
nonstratified constructive negation and disjunction operators from ITE against
the clp(FD)operators #\
and #\/
as well as against the global
constraint smt [2]. smt is a constraint that
potentially allows stronger and faster propagation of reifiable constraints than
the default propagators of clp(FD), but not necessarily in all cases.
For operators with stratified reasoning, we experiment with different settings of the parameter , which is adjusted to , , , , and times the number of disjunctive operators in the formula, rounded to the next smallest integer. We tested multiplication factors larger than , but did not find better results, so we ignore them here. To evaluate the performance on the benchmark set, we both analyze the time to propagate the expressions and the resulting domain sizes. All expressions in the benchmark set can be resolved to finite domains, therefore we count propagations that do not return finite domains as incomplete propagations.
The experimental results, shown in figures 5 and 6, illustrate a tradeoff between time for successful propagation and resulting domain size. Propagation via the builtin clp(FD)constraints is the quickest approach, although it does not necessarily propagates every expression to a finite domain. ITE successfully propagates all expressions in the benchmark set, although with time longer than clp(FD), but shorter than smt. The results for the smt constraint are ambivalent as well. Propagation via smt is slower than native clp(FD)constraints, but more efficient in domain pruning, as it is also the case for ITE. However, the time of smt is much higher than of ITE and by choosing an appropriate value for , ITE is more efficient in reducing the domain size.
Opt.  +50%  +100%  No Sol.  

cd/2  100  0  0  0  0 
cd/3 (*0.9)  50  7  7  11  25 
cd/3 (*1)  100  0  0  0  0 
cd/3 (*1.25)  100  0  0  0  0 
cd/3 (*1.5)  100  0  0  0  0 
cd/3 (*2)  100  0  0  0  0 
clp(FD)  43  7  4  14  32 
smt  54  7  4  18  18 
Conclusively, for the tradeoff between propagation time and resulting domain size, ITE is a beneficial choice, even without stratified reasoning. With stratified reasoning, choosing a value for that is close to the number of disjunctive operators in the formula shows best performance.
Vi Conclusion
In this paper, we have introduced a lightweight implementation of constructive disjunction and negation in Prologbased CSP solvers. This implementation, called ITE, provides a variety of operators which are useful to explore logical combination of constraints. By exploiting absentailment, a powerful relaxation of entailment, and a global constraint definition mechanism, such an implementation is straightforward. As there is a risk of combinatorial explosion, our implementation provides stratified deduction, which is a userparameterized technique to cope with the problem of disjunctive reasoning. Stratified deduction requires only to set up a single parameter, for which we provide a selection guideline.
Our experimental results show that ITE is competitive with available tools to deal with disjunctive reasoning, namely domain and interval entailment and the smt global constraint. As future work, we plan 1) to propose to automatically adjust the value of
for stratified reasoning through heuristic reasoning and 2) to explore the capability to infer more symbolic information from disjunctions than just pure domain information. The later proposition would require to propagate not only domains, but also deduced variable relations. This is a challenging problem as there does not exist any general recipe to perform the union of symbolic information in CSP solving.
References
 [1] Nicolas Beldiceanu, Mats Carlsson, Sophie Demassey, and Emmanuel Poder. New filtering for the cumulative constraint in the context of nonoverlapping rectangles. Annals of Operations Research, 184(1):27–50, Apr 2011.
 [2] Nicolas Beldiceanu, Mats Carlsson, Pierre Flener, and Justin Pearson. On the reification of global constraints. Constraints, 18(1):1–6, 2013.
 [3] B. Carlson, M. Carlsson, and D. Diaz. Entailment of Finite Domain Constraints. In Proc. of 11th International Conference on Logic Programming. MIT Press, 1994.
 [4] M. Carlsson, G. Ottosson, and B. Carlson. An Open–Ended Finite Domain Constraint Solver. In Prog. Lang., Impl., Logics, and Programs (PLILP), 1997.
 [5] Stefano Di Alesio, Shiva Nejati, Lionel Briand, and Arnaud Gotlieb. Stress testing of task deadlines: A constraint programming approach. In Int. Symposium on Soft. Reliability and Engineering (ISSRE’13), Research track, Pasadena, CA, USA, Nov. 2013.
 [6] Minh Binh Do and Subbarao Kambhampati. Planning as constraint satisfaction: Solving the planning graph by compiling it into CSP. Artif. Intell., 132(2):151–182, 2001.
 [7] François Fages. Constructive negation by pruning. J. Log. Program., 32(2):85–118, 1997.
 [8] A. Gotlieb, T. Denmat, and B. Botella. Constraintbased test data generation in the presence of stackdirected pointers. In 20th IEEE/ACM International Conference on Automated Software Engineering (ASE’05), Long Beach, CA, USA, Nov. 2005. 4 pages.
 [9] A. Gotlieb and M. Petit. A uniform random test data generator for path testing. The Journal of Systems and Software, 83(12):2618–2626, Dec. 2010.
 [10] Pascal Van Hentenryck, Vijav Saraswat, and Yves Deville. Design, implementation, and evaluation of the constraint language cc(fd). Journal of Logic Programming, 37:139–164, 1998. Also in CS9302 Brown–University 1993.
 [11] Mikael Z. Lagerkvist and Christian Schulte. Propagator groups. In Principles and Practice of Constraint Programming  CP 2009, 15th International Conference, CP 2009, Lisbon, Portugal, September 2024, 2009, Proceedings, pages 524–538, 2009.
 [12] Christophe Lecoutre. Constraint Networks: Techniques and Algorithms. ISTE/Wiley. ISBN 9781848211063, 2009.
 [13] Kim Marriott and Peter J. Stuckey. Programming with Constraints : an Introduction. The MIT Press, 1998.

[14]
Neil CA Moore and Patrick Prosser.
The ultrametric constraint and its application to phylogenetics.
Journal of Artificial Intelligence Research
, 32:901–938, 2008.  [15] Morten Mossige, Arnaud Gotlieb, Helge Spieker, Hein Meling, and Mats Carlsson. Timeaware test case execution scheduling for cyberphysical systems. In Proc. of Principles of Constraint Programming (CP’17), Aug. 2017.
 [16] Bertrand Neveu, Gilles Chabert, and Gilles Trombettoni. When interval analysis helps interblock backtracking. In International Conference on Principles and Practice of Constraint Programming, pages 390–405. Springer, 2006.
 [17] Charles Prud’homme, JeanGuillaume Fages, and Xavier Lorca. Choco Documentation. TASC  LS2N CNRS UMR 6241, COSLING S.A.S., 2017.
 [18] F. Rossi, P. van Beek, and T. Walsh, editors. Handbook of Constraint Programming. Elsevier, 2006.
 [19] Christian Schulte and Peter J. Stuckey. Efficient constraint propagation engines. Transactions on Programming Languages and Systems, 31(1):2:1–2:43, December 2008.
 [20] Gilles Trombettoni and Gilles Chabert. Constructive interval disjunction. In Principles and Practice of Constraint Programming  CP 2007, 13th International Conference, CP 2007, Providence, RI, USA, September 2327, 2007, Proceedings, pages 635–650, 2007.
 [21] Ioannis Tsamardinos and Martha E Pollack. Efficient solution techniques for disjunctive temporal reasoning problems. Artificial Intelligence, 151(1):43 – 89, 2003.
 [22] Jörg Würtz and Tobias Müller. Constructive disjunction revisited. In 20th Annual German Conference on Artificial Intelligence (KI’96), Dresden, Germany, pages 377–386, 1996.
Comments
There are no comments yet.