Formally Verified Transformation of Non-binary Constraints into Binary Constraints
aa r X i v : . [ c s . P L ] S e p Formally Verified Transformation of Non-binaryConstraints into Binary Constraints
Catherine Dubois
Samovar, ENSIIE, Évry, France [email protected]
Abstract.
It is well known in the Constraint Programming communitythat any non-binary constraint satisfaction problem (with finite domains)can be transformed into an equivalent binary one. One of the most well-known translations is the Hidden Variable Encoding. In this paper weformalize this encoding in the proof assistant Coq and prove that anysolution of the binary constraint satisfaction problem makes it possibleto build a solution of the original problem and vice-versa. This formaldevelopment is used to complete the formally verified constraint solverdeveloped in Coq by Carlier, Dubois and Gotlieb in 2012, making it atool able to solve any n-ary constraint satisfaction problem, The key ofsuccess of the connection between the translator and the Coq binarysolver is the genericity of the latter.
Constraint Programming or Constraint Satisfaction Problems [14] have manyreal-life applications such as decision making, resource allocation, scheduling,vehicule routing, configuration, planning, program verification, etc. Models aremade of variables, domains which define the possible values of the variables andconstraints which restrict the space of solutions. For example, modelling a Su-doku game requires 9*9 variables representing the different cells, their domain isthe interval 1..9 and the constraints impose that the numbers in the cells must beall different in each column and each line, and that in each square we must findall the numbers from 1 to 9. Here constraints can be expressed using the special-ized n-ary constraint
AllDifferent [12]. Complex problems are usually naturallymodelled with constraints involving a large number of variables. Historically, re-search in this area has focussed on binary constraints, i.e constraints using onlytwo distincts variables. Then some transformations allowing to translate a non-binary problem containing constraints involving more than two variables, intoan equivalent binary problem have been proposed, one of them is the HiddenVariable Encoding (HVE) [13], well-known in the Constraint Programming com-munity. In this paper, we formalize this encoding in Coq and prove that it doesprovide an equivalent encoding, in the sense that any solution of the encodingbinary problem can be translated into a solution of the original non-binary prob-lem and vice-versa. Furthermore if the original problem is unsatisfiable, then theencoding is also unsatisfiable and vice-versa.his formal development related to HVE is used to extend the formallyverified constraint binary solver developed in Coq by Carlier, Dubois and Gotliebin 2012 [5], called
CoqbinFD , making it a solver able to solve any n-ary problem.As far as we know, we provide here the first non-binary constraint solver (forfinite domains) formally verified, extracted from a Coq development. It can serveas a reference solver for testing other constraint solvers. It can be compared to theverified LTL model checker developed in Isabelle/HOL proposed as a referenceimplementation in [8]. It is also a brick of a formal library dedicated to formalizeresults and classical algorithms about constraints, in the spirit of the projectIsaFoL (Isabelle formalisation of Logic) which includes e.g. the formalisationin Isabelle/HOL of a CDCL-based SAT solver using efficient imperative datastructures [9].In [6], we have presented such an encoding verified in Coq for ternary con-straints only. This intermediate step was helpful to achieve the n-ary general-ization. The two Coq formalisations are close and follow the same process. Themain lemmas and theorems are if not identical, very close to each other. Thereason why we have first done the ternary case is historical: the translation wasimplemented in OCaml to encode non-binary arithmetic constraints as a set ofternary constraints (it can always be done as long as only binary and unary op-erators occur in the non-binary constraint) in order to use CoqbinFD . Then wedecided to push this transformation into Coq and to verify it for finally achievethe formalisation we present in tis paper. The ternary version does not take intoaccount extensional constraints.The paper is organized as follows. Section 2 briefly presents the notion ofconstraint satisfaction problem, the main ingredients of a constraint solver andthe Hidden Variable Encoding. Section 3 describes the Coq formalisation of theHidden Variable Encoding and highlights the proven properties. Then Section4 introduces the main characteristics of
CoqbinFD . Section 5 presents the ex-tended solver, obtained by reusing
CoqbinFD and also some experimentations.We conclude in the last section. A Constraint Satisfaction Problem (csp for short) or network of constraints [10]is a triple ( X, D, C ) where X is a set of variables, C is a set of constraints over X and D is a function that associates a finite domain D ( x ) to each variable x in X . Constraints are relationships between variables, each taking a value in theirrespective domain: constraints restrict possible values that variables can take.As often in CP literature, we assume that constraints are normalized, meaningthat two distinct constraints cannot hold over exactly the same variables. Thearity of a constraint is the number of its variables (assumed as distinct). A n -arycsp contains k -ary constraints with k ≤ n . A csp is said non-binary as soon as itcontains a constraint whose arity is strictly greater than 2. We do not consider https://bitbucket.org/isafol/isafol/wiki/Home nary constraints since the constraint can be directly taken into account in thedomain. A solution is defined as a total assignment of the csp variables whichsatisfies all the constraints simultaneously.Let us consider as an example the following non-binary csp ( X, D, C ) where X = { x , x , x , x , x , x } , D ( v ) = { , } for all v in X and C = { c : x + x + x = 1 , c : x + x − x + x = 1 , c : x + x − x ≥ , c : x + x − x = 0 , c : x ≥ x } inspired from [19]. It has a unique solution defined as { x , x , x , x , x , x } .A constraint solver usually alternates propagation and exploration. Propa-gation prunes the domains of the variables, removing inconsistent values, usingthe constraints. This step can be decomposed in 2 interleaved routines: filter-ing that removes inconsistent values from the domains of the variables of oneconstraint and propagation that determines the constraints that have to be vis-ited after a filtering step until a fixpoint is reached. Exploration enumeratesvalues for some variables and may backtrack on these choices if necessary. Thepropagation step enforces a local consistency property that characterizes somenecessary conditions on values to belong to solutions. There exist many differentlocal consistencies, e.g. arc consistency, path consistency or bound consistency[3]. One of the oldest is Arc Consistency (when applied to binary constraints)or Generalized Arc Consistency (as a generalization of AC to n-ary constraints).Let c be a constraint of a csp ( X, D, C ) whose variables are x , x . . . x k . Theconstraint c is (generalized) arc-consistent with respect to the csp if and only iffor each variable x i , for each value v in D ( x i ) , there exist possible values for theother variables of the constraint c that make it true. Thus filtering c consists inremoving the values of x , x . . . x k that invalidate that property. In the previousexample, c is generalized arc consistent with respect to the given csp. Howeverif we modify the domain of x as the singleton { } , c is not anymore generalizedarc consistent because when x has the value 1, there is no value for x that canmake the constraint true. In such a case, a filtering algorithm would remove thevalue 1 from the domain of x .Decomposition of non-binary constraints into equivalent binary constraintsis a subject that has been widely discussed in the CP community and for quitea long time. A well-known transformation for constraint satisfaction problemswith finite domains is the Hidden Variable Encoding (HVE) [13]. recognized ashaving nice theoretical properties [11]. In HVE, every non-binary constraint isassociated with a variable whose domain is the set of all possible tuples of theoriginal constraint, i.e. the set of tuples (of values of involved variables in theconstraint) that satisfy the constraint. Such a variable is called a dual variable and written v c if c denotes the constraint. Thus the variables of the equivalentbinary csp are the variables of the original csp called original variables and thedual variables. The domains of the original variables remain identical to theirdomain in the original csp. Non-binary constraints do not appear in the binaryencoding: they are replaced by hidden constraints between a dual variable andeach of the original variables in the constraint represented by the dual variable.A hidden constraint enforces the condition that a value of the original variableust be the same as the value assigned to it by the tuple that is the value ofthe dual variable [2]. In the following we denote them informally as projections: proj , proj , . . . A mathematical definition of this transformation (called the hidden transformation ) can be found in [2] (see Definition 7).As an illustration, the binary csp resulting from the HVE transformationapplied on the example presented previously has 10 variables: the 6 originalones and 4 dual variables v c , v c , v c and v c . Domains of original variablesremain identical whereas domains of the dual variables are such that D ( v c ) = { (0 , , , (0 , , , (1 , , } , D ( v c ) = { (0 , , , , (0 , , , , (0 , , , , (1 , , , , (1 , , , , (1 , , , } , D ( v c ) = { (0 , , , (1 , , , (1 , , , (1 , , } and D ( v c ) = { (0 , , , (0 , , , (1 , , } .There are 14 binary constraints: the original binary constraint c and 13 hiddenconstraints, e.g. proj ( v c , x ) , proj ( v c , x ) . The Coq formalisation follows the definition given previously, a csp is encodedas a record, of type network n (see its definition in the code snippet below) con-taining a list of variables, a map from variables to domains (of type domain n ),represented as lists of values and a list of constraints. Types of variables ( vari-able n ) and values ( value n ) are abstract, they can be further defined either inCoq or in OCaml when extraction is used. We expect value n and variable n tobe equipped with a strict total order and a decidable equality. Constraints (seebelow the definition of the type constraint n ), either binary or non-binary, arealso abstract but the arity of a constraint is made explicit. It means that thetype of basic constraints ( basic constraint ) is abstract, equipped with a functionto get the variables and an abstract interpretation function (as in
CoqbinFD ).A non-binary constraint is defined by a value of the abstract type OP , its arityand a list of variables. In order to be as general as possible, we consider exten-sional constraints as well as intentional ones. In the former case, the semanticsis given as a list of acceptable tuples, in the latter case, a boolean functionis expected. Constraint c of the example given in Section 2 is represented as Nary3 p1 [x1 ; x2 ; x6] where p1 is associated to the interpretation function f ( a, b, c ) := a + b + c − . Inductive constraint n : Set := | Bin : basic constraint → constraint n | Nary : OP → nat → list variable n → constraint n . Inductive interpretation : Set := | Extension : list ( list value n ) → interpretation | Intention : ( list value n → bool ) → interpretation . Record network n : Type := Make cspn { CVarsn : list variable n ; omsn : domain n ; Cstsn : list constraint n }.Our formalisation choice requires some extra properties about the input con-straints language definition, in particular about the interpretation functions, forexample basic interp should only be defined for lists of length 2 (should failfor other cases) or the table defining an extensional k -ary constraint should onlycontain tuples with k components. These requirements can be checked at ex-traction time, e.g. by testing. They appear in our Coq development as axiomsor parameters, in a weak form discovered during the proof of some properties. Parameter interp op length extension : ∀ op ar table , interp op op ar = Extension table → ∀ l , In l table → length l = ar .The modelling of constraints is as simple as possible. It allows ill-formedconstraints. The ability to deal with potentially ill-formed constraints makes thedefinition of some functions easier. We define well-formedness in a separate wayas the predicate named network inv n , the property is implicitly introducedwhen needed.The predicate network inv n specifies the following requirements: – variables in constraints are exactly the ones that are listed in the csp anddefined in the domain map; – constraints are normalized, meaning that they do not share the same set ofvariables; – basic binary and Nary constraints have distinct variables; – in the case of a Nary constraint of arity k represented by Nary op k l , thelength of the list of variables l is exactly k , with k strictly greater than 2.An alternative way would have been to use dependent types for constraints,giving to the constructor Nary the following type forall n, vector n -> OPn -> constraint n where vector n is the type of lists of length n et OP n thedependent version of the type OP . So a lot of types would become dependent.Another reason not to use dependent types is that we want to be able to easilydefine the constraints language in OCaml that does not provide such dependenttypes. A last reason is that the formalization presented in this paper generalizesthe proofs done for ternary constraints [6] and follows the same line. A binary csp (as it is encoded in
CoqbinFD ) has a very similar representation,it is a record containing a list of variables, a table that maps variables to finitedomains and a list of binary constraints. We define in this subsection the vari-ables, the values and the constraints of a binary csp resulting from the HVEtranslation. The type of variables, variable , is defined inductively and reflectsthat variables are either original variables (introduced by the constructor
OVar )or hidden variables (constructor
HVar ). The latter variables are defined w.r.tn original constraint. We make explicit this association in the way we buildvariables. For example, the hidden variable v c of the example given in Section 2is encoded in Coq as HVar p1 3 [x1; x2; x6] . Inductive variable := | OVar : variable n → variable | HVar : OP → nat → list variable n → variable .The type of values, value , is also defined inductively, it distinguishes rawvalues, which are the original variables values, from tuples which are the hiddenvariables values. Inductive value := | Raw value : value n → value | Tuple : nat → tuple value .A decidable equality and a strict order are defined for both types, followingfrom the required equalities and orders on value n and variable n .We can now define the type constraint whose values are the original binaryconstraints and the hidden constraints. In our example, the hidden constraintbetween v c and the second original variable is represented in Coq by Proj p1 3[x1; x2; x6] 1 x2 . We prove the properties on the constraint language requiredby
CoqbinFD , e.g. any constraint has distinct variables.
Inductive constraint : Set := | Basic : basic constraint → constraint | Proj : OP → nat → list variable n → nat → variable n → constraint . The Coq function, translate csp n , that translates a non-binary csp into a bi-nary csp, closely follows the presentation in Section 2 and the mathematicaldefinition given in [2]. It uses several intermediate functions, in particular thefunction expand that computes the domain of a hidden variable, as a list of tu-ples, from the interpretation function and the domains of the ordinary variablesof the constraint corresponding to the hidden variable. The computed domaincontains only the tuples that satisfy the interpretation. In the case of an exten-sional non-binary constraint, the domain of the corresponding hidden variable isobtained by copying the table given as its interpretation. It also uses the function cstsnTocsts2 which computes, for a list of constraints, the list of original binaryand hidden constraints and the list of hidden variables coupled with their listof tuples computed with the help of expand . The ordinary binary constraintsof the original csp and the corresponding domains are just copied modulo someelementary rewriting. The map containing the domains of the hidden variablesis built with the help of the function new domain .Except some minor differences and the definition of the function expand , thefunction is similar to the one in the ternary case [6].
Definition translate csp n cspn := match ( cstsnTocsts2 ( Cstsn cspn ) (
Domsn cspn ) ) with
None ⇒ None | Some ( cs , lvdv ) ⇒ Some ( Make csp ( List.app ( List.map ( fun x ⇒ OVar x ) (
CVarsn cspn )) (
List.map fst lvdv ))( new domain ( mapn to raw ( Domsn cspn ) (
CVarsn cspn )) lvdv ) cs ) end .Note that translate csp n may fail when cstsnTocsts2 tries to access thedomain of unknown variables. We prove that if the non-binary csp is well-formedthen the translation does not fail: Lemma network inv n translate None False : ∀ cspn , network inv n cspn → ¬ ( translate csp n cspn = None ).We also prove that the binary csp obtained by HVE is well-formed if theoriginal csp is well-formed:
Lemma translate cspn network inv : ∀ cspn csp , network inv n cspn → translate cspn cspn = Some csp → network inv csp . Let us focus on the expand function that, in the case of an intentional constraint,computes the set of tuples. It is merely the computation of the cartesian productof k lists if the arity of the constraint is k . We first compute the result as a listof lists (of length k ) representing the tuples. Then we turn these lists into tupleswhose type is abstract with the help of an abstract function tuple from list introduced as a parameter. Yes, this step requires a computational overhead butit allows some flexibility at extraction time. For example we can map the type tuple to the OCaml array type in order to benefit from a constant time access.We can also keep lists by mapping tuple from list to the identity function.Besides tuple from list , we need 2 other functions: tuple to list (of type nat-> tuple -> value n ) and proj tuple (of type nat -> tuple -> value n ). Thefirst one is not used in the translation itself but only in the proofs. These func-tions are specified by 3 properties or axioms which are given below: Parameter tuple to from list : ∀ a , tuple to list ( length a ) ( tuple from list a ) = a . Parameter proj tuple nth error : ∀ n n0 t v0 , n > 0 → n0 < n → proj tuple n0 t = v0 ↔ nth error ( tuple to list n t ) n0 = Some v0 . Parameter length tuple to list : ∀ n t , length ( tuple to list n t ) = n .In order to gain some more confidence when we extract OCaml code fromthe Coq code, we have tested these 3 properties using the QuickChick propertytesting tool for Coq programs [7] with 10000 test cases randomly generated.t allowed the discovery of a missing hypothesis (the blue one in the secondstatement).An alternative could be to use primitive persistent arrays in the Coq codefor implementing tuples (without going through intermediate lists). The type ofsuch arrays is axiomatized (in the PArray module). Primitive arrays internallyare implemented using a persistent data structure. This has been very recentlyintegrated into the current version of Coq. It was previously available as a sepa-rate implementation [1]. We plan to experiment with these primitive arrays. Thecartesian product of domains implemented in the expand function is a bit morecomplicated when dealing with arrays.A last proposition could be to implement tuples as finite functions, and thento use the coq library proposed by Sakaguchi in [16] to extract these tuples toOCaml arrays.
To prove the correctness of the translation, we prove that satisfiability is pre-served by the HVE translation. Two related properties are illustrated below.A solution is defined as usual as an assignment of the csp variables which istotal, valid (i.e. values are compatible with the domains) and locally consistent(i.e. making each constraint satisfied). It is implemented as a map from vari-ables to values. A solution of a non-binary csp (resp. a binary encoding csp) ischaracterized by the predicate solution n (resp. solution ).Lemma translate nosol states that if the original non-binary csp is UNSAT(i.e. it admits no solution) then the binary encoding is also UNSAT. Lemma translate complete explains that if the non-binary csp admits a solution, a n ,then its mapping to the hidden and original variables (computed by the function translate sol n ) is a solution of the binary encoding.
Lemma translate nosol : ∀ cspn csp , network inv n cspn → translate csp n cspn = Some csp → ( ∀ a , ¬ ( solution a csp )) → ∀ an , ¬ ( solution n an cspn ). Lemma translate complete : ∀ an cspn csp , network inv n cspn → translate csp n cspn = Some csp → solution n an cspn → solution ( translate sol n an cspn ) csp . CoqbinFD
In this section we briefly describe the binary solver
CoqbinFD that we want toreuse. For more details please consult [5]. An important point in this developmentand crucial for the present work is its genericity. In the following we mainlyemphasize the requirements upon the generic parameters. The solver is indeedparameterized by the type of variables ( variable ) and values ( value ) and also bythe constraint language ( constraint ). In Coq, these types are abstract, assumedo accept a decidable equality. It is also assumed that the semantics of theconstraints is given by an interpretation function as a Boolean function of thevalues of its two variables and a function that retrieves, for any constraint, its twovariables. So a constraint is abstracted as a relation over two distinct variables,represented by an interpretation predicate. These types and functions must bedefined either in Coq or directly in OCaml in order to use the extracted solverin a particular context. Here they will be given Coq concrete values accordingto HVE.A csp is defined as a record of type network csp consisting of a finite listof variables (
CVars field), a finite list of constraints (
Csts ) and a map (
Doms )associating each domain with its variable, here a finite list of values. A pred-icate ( network inv ) specifies the well-formedness of a csp: the entries of thedomain map are exactly the variables of the csp, variables appearing in the con-straints are exactly those declared, constraints are normalized and finally thetwo variables of any constraint are distinct.The solving process is based on arc-consistency, it implements a generic ver-sion of the propagation algorithm AC3 [10], allowing the use of AC2001 [10].However in our work, it is transparent, the binary solver being used as a black-box.
CoqbinFD to Non-binaryConstraints
We propose to build a constraint solver able to deal with binary and non-binary constraints by extending the
CoqbinFD solver (whose main function isthe solve csp function) with the HVE translation acting as a pre-processor andthe solution translation acting as a post-processing. The different steps are il-lustrated on Fig. 1. cspn HVE csp2
CoqbinFD sol2 / unsattranslatesoln / unsat
Fig. 1.
Behavior of the Non-binary Solver
The extended solver is mainly embodied by the following solve n functionwhich follows the steps of Fig. 1 and is built using the tactic
Program [17] (asits counterpart in
CoqbinFD ): Program Definition solve n ( cspn : network n ) ( Hn : network inv n cspn ): { res : option ( assign n ) | result n ok res csp } := atch ( translate csp n cspn ) with None ⇒ None | Some csp ⇒ match ( solve csp csp ) with None ⇒ None | Some a ⇒ Some ( translate sol a cspn.CVarsn ) endend .The type of the result is a kind of subtype Ãă la PVS , it describes not only thetype of the computed result res ( None or a Nary solution) but it also contains aproof that the result is sound (specified by the predicate result n ok ), i.e. if theresult is
None then the original csp has no solution and if it is
Some a , then a is a solution of the original csp. This definition generates proof obligations thatcorrespond to the expected properties of the result. Another proof obligationcomes from the underscore appearing in the call of solve csp that expects asa third argument a proof that its second argument is well-formed. This proofobligation is solved by the lemma translate cspn network inv shown previouslyin Subsection 3.3.Completeness of the extended solver is also proved. It follows from the com-pleteness of CoqbinFD and from the properties of the translate sol n functionregarding solutions.The main task to extend
CoqbinFD to Nary constraints is to provide thebinary encoding exactly as it is expected by
CoqbinFD . As this solver is genericin the input constraint language, the task was made easier.After extraction, we ran the extended solver (with the AC3 instance of
Co-qbinFD ) to solve some problems. First we have used it with binary and ternarycsps, for non-regression testing. The time overhead is not significant. We alsosolved some problems, intensional and extensional ones, from the XCSP2.1 li-brary [15] where csps are represented as XML definitions. For example the prob-lem named normalized g 4x4 with 16 variables with { , } as domain and 15constraints with arity from 3 to 5 is solved in 0.0033 sec on a laptop (2,3 GHzIntel Core i5 8 Go 2133 MHz LPDDR3) whereas for the problem known as normalized-graceful-K2-P3 with 15 variables (whose domain is either 0..9 or1..9) and 60 constraints, 9 of them being ternary and the rest being binary, weobtain a solution in 2.8 sec.The manual transcription of XCSP2.1 problems in OCaml is however tediousand error prone. Our solver could be completed with a tool allowing the trans-lation of XML definitions into OCaml or Coq definitions. Following Stergiouand Samaras in [18], we could obtain a better efficiency by using specialized arcconsistency and search algorithms for the binary encodings requiring to furtherprove some variants for propagation and exploration algorithms. In this paper we have formalized in Coq the well-known Hidden Variable Encod-ing that performs the translation of a non-binary constraint satisfaction problemnto an equivalent binary constraint satisfaction problem. This translation is usedto extend the
CoqbinFD solver, developed in Coq several years ago. The Coq codeis available at . From the whole Coq devel-opment, an OCaml executable solver can be extracted. It can be considered as areference implementation and used to test other solvers, for example the FaCiLeOCaml constraint library [4].
References
1. M. Armand, B. Grégoire, A. Spiwack, and L. Théry. Extending coq with im-perative features and its application to SAT verification. In M. Kaufmann andL. C. Paulson, editors,
Interactive Theorem Proving, First International Confer-ence, ITP 2010, Edinburgh, UK, July 11-14, 2010. Proceedings , volume 6172 of
Lecture Notes in Computer Science , pages 83–98. Springer, 2010.2. F. Bacchus, X. Chen, P. van Beek, and T. Walsh. Binary vs. non-binary constraints.
Artificial Intelligence , 140(1):1 – 37, 2002.3. C. Bessière. Constraint propagation. In
Handbook of Constraint Programming ,chapter 3. Elsevier, 2006.4. P. Brisset and N. Barnier. FaCiLe : a Functional Constraint Library. In
CICLOPS2001, Colloquium on Implementation of Constraint and LOgic Programming Sys-tems , Paphos, Cyprus, 2001.5. M. Carlier, C. Dubois, and A. Gotlieb. A Certified Constraint Solver over FiniteDomains. In
Formal Methods (FM) , volume 7436 of
LNCS , pages 116–131, Paris,2012.6. C. Dubois. Formally verified decomposition of non-binary constraints into equiva-lent binary constraints. In N. Magaud and Z. Dargaye, editors,
Journées Franco-phones des Langages Applicatifs 2019 , Les Rousses, France, Jan. 2019.7. M. DÃľnÃĺs, L. Lampropoulos, Z. Paraskevopoulou, and B. C. Pierce. Quickchick:Property-based testing for coq, 2014.8. J. Esparza, P. Lammich, R. Neumann, T. Nipkow, A. Schimpf, and J. Smaus. AFully Verified Executable LTL Model Checker. In N. Sharygina and H. Veith,editors,
Computer Aided Verification 2013, Saint Petersburg, Russia , volume 8044of
LNCS , pages 463–478. Springer, 2013.9. M. Fleury, J. C. Blanchette, and P. Lammich. A verified SAT solver with watchedliterals using imperative HOL. In J. Andronick and A. P. Felty, editors, , pages 158–171. ACM, 2018.10. A. Mackworth. Consistency in Networks of Relations.
Art. Intel. , 8(1):99–118,1977.11. N. Mamoulis and K. Stergiou. Solving non-binary Csps using the hidden Variableencoding. In T. Walsh, editor,
Principles and Practice of Constraint Programming- CP 2001, 7th Int. Conference, CP 2001, Paphos, Cyprus , volume 2239 of
LNCS ,pages 168–182. Springer, 2001.12. J.-C. Régin. A Filtering Algorithm for Constraints of Difference in CSPs. In , pages 362–367, 1994.13. F. Rossi, C. J. Petrie, and V. Dhar. On the Equivalence of Constraint SatisfactionProblems. In
ECAI , pages 550–556, 1990.14. F. Rossi, P. van Beek, and T. Walsh.
Handbook of Constraint Programming . Else-vier Science Inc., USA, 2006.5. O. Roussel and Christophe Lecoutre. XML representation of Constraint networks:Format XCSP 2.1.
CoRR , abs/0902.2362, 2009.16. K. Sakaguchi. Program extraction for mutable arrays.
Sci. Comput. Program. ,191:102372, 2020.17. M. Sozeau. Subset coercions in coq. In T. Altenkirch and C. McBride, editors,
Types for Proofs and Programs, International Workshop, TYPES 2006, Notting-ham, UK, April 18-21, 2006, Revised Selected Papers , volume 4502 of
Lecture Notesin Computer Science , pages 237–252. Springer, 2006.18. K. Stergiou and N. Samaras. Binary encodings of non-binary constraint satisfactionproblems: Algorithms and experimental results.
J. Artif. Intell. Res. , 24:641–684,2005.19. K. Stergiou and T. Walsh. Encodings of Non-Binary Constraint Satisfaction Prob-lems. In J. Hendler and D. Subramanian, editors,