Paper deep dive
Learning Size Independent Constraint Models from Input Data and Positive and Negative Example Solutions
Helmut Simonis
Intelligence
Status: succeeded | Model: Gemma-4-26B-A4B | Prompt: intel-v1 | Confidence: 94%
Last extracted: 10/13/2026, 2:51:50 AM
Summary
This paper introduces a Constraint Acquisition Tool that generates size-independent constraint models from input data and positive/negative example solutions of multiple problem instances. The system identifies size-specific models based on global and binary constraint patterns, then generalizes them into a generic model executable in MiniZinc. The approach is evaluated on the PTHG21 Challenge benchmarks, demonstrating feasibility in handling structured data, hidden variables, and producing both code and natural language explanations.
Entities (8)
Relation Signals (6)
Helmut Simonis → affiliatedwith → University College Cork
confidence 95% · Helmut Simonis# School of Computer Science and Information Technology, University College Cork, Ireland
Constraint Acquisition Tool → evaluatedon → PTHG21 Challenge
confidence 95% · We evaluate the tool on the example problems of the PTHG21 Challenge
Constraint Acquisition Tool → producesoutput → MiniZinc
confidence 95% · The system produces MiniZinc code as well as a textual description of the model.
Constraint Acquisition Tool → influencedby → ModelSeeker
confidence 90% · The major influences of the current system are the ModelSeeker
Constraint Acquisition Tool → utilizesresource → Global Constraint Catalog
confidence 90% · The Global Constraint Catalog provides such checkers for most constraints
Constraint Acquisition Tool → usesinput → BIBD
confidence 85% · we use a running example, which is based on the BIBD (Balanced Incomplete Block Design) problem.
Cypher Suggestions (0)
No Cypher suggestions yet.
Abstract
Abstract:In this paper we describe a Constraint Acquisition Tool that generates size independent constraint programs from input data and positive and negative example solutions of multiple problem instances. The system finds size specific models based on typical constraint patterns over global and binary constraints, then generalizes the models to a size independent model that can be run on unseen input data. The system produces MiniZinc code as well as a textual description of the model. We evaluate the tool on the example problems of the PTHG21 Challenge and show the feasibility of the approach.
Tags
Links
- Source: https://arxiv.org/abs/2610.13640v1
- Canonical: https://arxiv.org/abs/2610.13640v1
Trouble viewing inline? Open PDF directly →
Full Text
58,303 characters extracted from source content.
Expand or collapse full text
Learning Size Independent Constraint Models from Input Data and Positive and Negative Example Solutions Helmut Simonis# School of Computer Science and Information Technology, University College Cork, Ireland Abstract In this paper we describe a Constraint Acquisition Tool that generates size independent constraint programs from input data and positive and negative example solutions of multiple problem instances. The system finds size specific models based on typical constraint patterns over global and binary constraints, then generalizes the models to a size independent model that can be run on unseen input data. The system produces MiniZinc code as well as a textual description of the model. We evaluate the tool on the example problems of the PTHG21 Challenge and show the feasibility of the approach. 2012 ACM Subject Classification Theory of computation→ Constraint and logic programming Keywords and phrases constraint acquisition, modelling, global constraints 1 Introduction Constraint Acquisition [14] is the process of defining a constraint model from a set of example solutions and non-solutions. In most of the existing literature, a model of a single problem instance is learned, which can then only be used to generate new solutions of the same problem, or perhaps the same problem with different domain bounds. In most practical CP applications, the actual constraint model heavily depends on input data. Consider a scheduling problem for a factory. Every day the set of orders that need to be scheduled will be different, and from time to time new products or processes will be introduced. A CP model for this factory needs to be able to create the appropriate constraint model for a given dataset, and change the specific constraints of the instance from one day to the next, due to different process steps or resources used. If we want to acquire a generic constraint model in this scenario, we have to understand how the number of variables, their domains, and the constraints depend on the input data. Having acquired the model, we then should be able to apply the model to a new, previously unseen set of input data, and solve the resulting model. This is a more challenging problem than the use case previously discussed in constraint acquisition, but, as this paper shows, this task is not out of reach at this point. The general use case we want to model is shown in Figure 1. We are given a set of input data, solutions and non-solutions for multiple problem instances of different sizes. Our constraint acquisition tool produces a generic model based on those problem instances. This model can then be fed, together with new, unseen input data, into an existing constraint solver to produce a solution for this new instance. The user can interact with the constraint acquisition to accept or reject certain constraints, in addition the users should be able to understand and extend the generated model if they so wish. This leads to the following set of properties that a generic constraint acquisition tool should have: diverse structureWe must be able to handle not just a single set of unstructured variables, but a collection of variables, vectors and matrices, and possibly more complex structures. We can exploit this structural information to find likely constraints linking multiple structures, which would be difficult to identify in an unstructured list. arXiv:2610.13640v1 [cs.AI] 9 Oct 2026 2Learning Size Independent Constraint Models Figure 1 Intended Use Case Input Data Solutions NonSolutions Instances, multiple sizes Constraint Acquisition Generic Model Unseen Input SolverSolution User hidden variablesThe variables described in the solution may not describe all variables used in the constraint model. Some derived variables, especially cost variables, may be missing from the samples, with only aggregate cost values presented. Our system should reconstruct such missing, hidden variables in order to find the complete constraint model. genericThe model should not be specific to one given instance only, but apply to a series of instances which are specified by different input data and parameter values. consistentThe generated model should be consistent, so that all given positive samples are accepted, and all negative samples are rejected. We are currently not handling the case where solutions or non-solutions are labelled incorrectly. minimal The model should not contain any constraints that are not required, in particular any subsumed constraint should be filtered out. transferableWe must be able to use the generated model on new, previously unseen input data, as long as the structure of the problem remains the same. executableIt is not enough to generate an abstract model, we should be able to execute the model with some existing constraint solver. In our case, we produce MiniZinc[27] code, which can then be run with a variety of back-end solvers. explainableWe should be able to explain the generated model to a user not familiar with specific constraint programming systems and languages. A natural language description of the model would provide a good initial explanation. efficient As we are solving combinatorially hard problems, we will not be able to solve every new problem instance. We consider the generated model efficient if its runtime is comparable to a handwritten program for the same problem written in a high-level modelling language like MiniZinc. The main contributions of this paper are: introduction of a more realistic constraint acquisition use case driven by practical needs generating size independent constraint models dealing with structured, positive and negative samples and input data simplifying the concept of partition generator in ModelSeeker [7] to allow for trivial generalization with an acceptable loss of flexibility producing executable constraint programs in MiniZinc, whose performance is comparable to hand-crafted code for the same problem H. Simonis3 producing a natural language, textual description of the generated model to explain the model to a user demonstrating the feasibility of the approach on all benchmark problems defined for the PTHG21 Challenge [40] The paper is structured in the following way. In the next Section we discuss related work, and influences on the current paper. In Section 3 we introduce a running example that we use throughout the presentation of the different elements of our system. Section 4 is the main part of paper, describing the different components of the tool. This is followed in Section 5 by an evaluation of the tool based on the problems in the PTHG21 Challenge. We conclude in Section 6 with a discussion of existing gaps, and future work. 2 Related Work Work on constraint acquisition started in the early 2000s, with [18,17,10]. Two main approaches developed, one (called "passive") based on labelled example solutions and non- solutions, and one (called "active") based on asking queries to a hypothetical user who knows the problem, but cannot express the constraints directly. A general overview of the literature is given in [14,13]. The work on active constraint acquisition [12,8,43,1,3,9,11,41] centres on the question of how many queries need to be asked, and which form these queries can take. More recent work has looked at extending constraint acquisition to other problem domains, like Integer Programming [37,24,25,31,30,29], SMT [21], SAT solving [23], or MAX- CSP [42]. An interesting, perhaps more immediately practical idea has been the extraction of formulas and structure from spreadsheets [22,15,20,28]. Another promising approach is limiting the acquisition problem to a specific problem domain, like time tabling [24] or scheduling [39]. This allows more specialized methods to be applied, and provides a vocabulary and background knowledge that can be exploited. There has been relatively little work on acquiring size independent models from multiple problem instances [26], and only more recently work on constraint acquisition with noisy data [35,34,32], for which a realistic use case has not yet been clearly defined. The case of active acquisition where certain queries cannot be answered by the user is explored in [44]. The major influences of the current system are the ModelSeeker [7,6] and the Global Constraint catalog [5,2]. ModelSeeker was acquiring instance specific constraint models expressed as a conjunction of global constraints based on few positive examples of unstructured solutions. We extend its idea of a partition generator to allow generalization of the patterns found, while dealing with structured data for both solutions and input data. Other elements of ModelSeeker, like the constraint subsumption check and ranking of candidate constraints have been reimplemented, but are fundamentally unchanged. The current system does not cover all constraints in the global constraint catalog, restricting itself to those which are already provided in MiniZinc, or for which simple decompositions could be provided, there are in total 50 global constraints defined in the system. The evaluation problems for the current system are taken from [40], which defined the input format and evaluation strategy followed. 3 A Running Example To illustrate the approach taken, we use a running example, which is based on the BIBD (Balanced Incomplete Block Design)[16] problem. A BIBD is defined as an arrangement ofv 4Learning Size Independent Constraint Models Table 1 Example Problem Instance (Problem 12, BIBD) Positive ExampleInput Parameters 1 1 1 1 1 0 0 0 0 0 1 1 0 0 0 1 1 1 0 0 1 0 1 0 0 1 0 0 1 1 0 1 0 1 0 0 1 0 1 1 0 0 1 0 1 0 1 1 1 0 0 0 0 1 1 1 0 1 0 1 1 "inputData": 2 "lambda": 2, 3 "v": 6, 4 "k": 3 5 , distinct objects intobblocks such that each block contains exactlykdistinct objects, each object occurs in exactlyrdifferent blocks, and every two distinct objects occur together in exactlyλblocks. The values forbandrcan be deduced from the valuesλ,v, andk. Instead of this integer formulation, a 0/1 incidence matrix with v rows and b columns is often used as an equivalent representation. The constraints then state that each row containsrones, each column containskones, and any two rows share ones inλcolumns. This form has been widely used in Constraint Programming [33,36], and features as problem 12 in our evaluation set. Figure 1 shows the first example solution of the (2,6,3) BIBD on the left. On the right we see the three corresponding input parameters (λ,v,k) in the JSON syntax of [40]. Altogether, we are given 20 problem instances of different sizes, each with a set of solutions and non-solutions. While for some problem sizes all solutions are given, for some of the larger problem sizes only a fraction of the complete solution set is provided. The non solutions were generated either by taking random assignment of the variables, or modifying existing solutions in a few places, while checking that they really are non solutions. Note that our acquisition process, given the 0/1 representation of the problem, will acquire the model in terms of 0/1 variables, and not in terms of the integer variables of the original definition. We are asked to find a model of the problem that, given new values for the input parameters, finds a solution matrix of 0/1 values of the correct size that satisfies all constraints of the problem. 4 System Description We now start with the description of the constraint acquisition tool. Its overall architecture is presented in Figure 2, which shows the main elements of the tool and how it is used in the evaluation process. The figure shows that a large number of individual components are needed to run and evaluate the acquisition tool. Most components are relatively simple, separating the overall acquisition process into more manageable pieces. There are three main parts of the system, from top to bottom. The first part produces instance specific models for each given problem instance, which can be used to check provided test cases for the given problem sizes. The second part generalizes these size specific models into one generic model that applies for all sizes. At this point we try to reduce the model by eliminating subsumed constraints, and by ranking constraints according to their interest. The third module produces an executable model in MiniZinc, while also providing a natural language description and a report on the acquisition process for the user. The generated code can then be used to find new solutions for unseen problem instances. Figure 2 also shows the data flow in the evaluation for the PTHG21 Challenge. The tool is used both for classifying test cases as solutions or non-solutions, and to produce new, H. Simonis5 additional solutions that were not given either as samples or test cases. In the following subsections we discuss each of these high-level modules in more detail. 4.1 Generating Size Specific Models This part of the acquisition process is quite similar to the ModelSeeker system, with some variations to allow generalization in the second stage. We build a size specific model of the given problem by looking for conjunctions of global constraints that apply to multiple, structured subsets of decision variables of the problem. We assume that these subsets are either defined by the problem structure (e.g. the rows of a matrix of variables), or given as input data (e.g. defining an index set in the input data which selects the elements of a matrix for which a constraint holds). This fundamental simplification makes the acquisition process manageable even for large problem instances. We do not have to search through an exponential number of possible subsets of the variables to identify the scope of a constraint. By considering index sets given as input data, we extend the type of constraints that can be found compared to the ModelSeeker, which had no general concept of input data, and could therefore only recognize regular constraint structures. 4.1.1 Transformation Generator The way the solution is presented may not be the best way for expressing some of the constraints of the system. In particular some variables of the problem may not be present in the solution description as they are dependent on other variables. We consider the following transformations: differenceA relatively common transformation occurs when a constraint is expressed on a set of difference variablesx i − x j over a set of given decision variablesx i instead of the decision variables themselves. Examples are the Golomb Ruler problem or Costas Array in the benchmark set. A number of variations (absolute value of differences, differences between consecutive, or between all different variables) are possible and must be treated as specific cases. absolute valueAnother transformation is the use of the absolute value of a decision variable instead of the variable itself. cost variablesA very common transformation occurs when, based on a decision variable, we encounter a cost variable, which depends on the decision value. We assume that the input data provide a cost vector or matrixdthat define the cost value for each value of the decision variables. We consider constraints of the formc i =d i ∗ x i as well asc i =d i,x i for implicit cost variablesc i which often occur in problems (like Warehouse Location in the benchmark set). projectionThe most general form of a transformation is a projection, when we use the projected value of a decision variable instead of the variable itself. A typical example would be using the machine type instead of the assigned machine itself to determine some resource constraint in a scheduling problem. As we assume the input data to describe the problem completely, we must find in the input data a vector (or matrix) which transforms a value for a decision variable into a projected domain. This imposes constraints on the size of the matrix that may be used in this way. We generate all of these transformed variables "on spec", in case we will use them to define some constraint of the problem, and retain only those transformations that were actually used. 6Learning Size Independent Constraint Models Figure 2 System Architecture and Evaluation Methodology Global Constraint Catalog Fixed Sizes Positive Examples Input Data Transformation Generator Pattern Generator Find Global Constraint Candidates Find Binary Constraint Candidates Binary Pattern Generator Size Specific Models Negative Examples Checker Rejection Rate Checker Testcases Prediction Parameter Formula Generator Generalizer Global Constraint Catalog Model Reduction Generic Model New Size Testcases Checker New Size Prediction Description Generator Code Generation MiniZinc Input Data Natural Lang. Description MiniZinc Code Report Generator Acquisition Report Backend Solver Generated Solutions Filter Positive Ex. Negative Ex. Testcases Extra Solutions Size Specific Model Generic Model Working CP Program Described Module Data Produced PTHG21 Benchmark Input Data Produced Benchmark Results Global Constraint Catalog External Actor Legend H. Simonis7 ModelSeeker was using additional transformations to deal with different problem repres- entations, e.g. using 0/1 variables instead of integer decision variables, or having multiple representations of successor variables in graph constraints. These are currently not included in our system, but could be added when required for future problems. 4.1.2 Pattern Generator The concept of pattern (or partition) generator was introduced for ModelSeeker in [4]. Patterns were specified by type and various parameter values, which allowed multiple interpretations of the same unstructured list of variables. This flexibility has a price, it is very difficult to generalize the partitions used for different problem sizes. We here use a simpler approach, which does not produce all partitions used in ModelSeeker, but were the patterns are trivial to generalize, and which exploits the structure of the data and samples given as input. Instead of formally defining each pattern, we explain the concept on an example. Figure 3 Pattern Generator for Matrix Signature Matrix/Matrices List List+Dvar List List+Dvar List+List List+List+Dvar List+List List+List+Dvar Matrix Matrix+Dvar List+List List+List+Dvar AllIndexedIndexed Matrix AllRowsAllColumnsBlocks square Diagonals square ConsecutiveRowsOrderedRowsDifferentRows ConsecutiveColumnsOrderedColumnsDifferentColumns MatrixTransposedMatrix PairedRowsPairedColumns Figure 3 shows the patterns that are currently used when dealing with a matrix (or 8Learning Size Independent Constraint Models multiple matrices). The first pattern uses the complete matrix and converts it into a single list of all elements. We then have two patterns that use index sets, the first selects the elements of the matrix identified by an index set into a list of variables, the second uses a second matrix as the index set. Elements of the first matrix that share the same index value in the second matrix are grouped together, resulting in a collection of lists of variables, which may or may not have the same size. The next line shows different ways of grouping elements of a matrix together. The first selects the elements of each row, the second the elements of each column, the thirds builds blocks of equal size, and the last selects the two main diagonals. Note that the last two patterns are only defined for squaren× nmatrices, with a block size of √ n. All previous patterns could be used for constraints with one list (and optional additional) argument. The next pattern apply to constraints that have two list arguments. We select two rows (resp. columns) of the matrix, either only consecutive rows, or ordered rows, or simply all different rows. Some constraints use the matrix itself as an argument, we allow that, as well as using the transposed matrix. This can be combined with additional list arguments (not shown). Finally, we use a pattern where we select corresponding rows or columns of two matrices and use them in constraints with two list arguments. 4.1.3 Binary Pattern Generator In a similar way, we can define the typical patterns that are used to set up binary constraints. We can of course have constraints between individual variables in a sample, but we assume that constraints over data structures are either of a regular form, or given by some index set in the input data. For a list of variables, we check if the same constraint applies between all different elements of the list, between ordered elements, or consecutive elements only. We also check if corresponding elements of two different lists are constrained by the same binary constraint. Some of the binary constraints modelled use a fixed integer constantcin their definition. We assume that only small values of these parameters are relevant, and restrict the range of values tested. 4.1.4 Finding Candidate Constraint Patterns Given some patterns and the original and transformed variables, we then apply each constraint with a matching signature to see if it satisfies each positive sample given. Constraints that do not hold for some positive sample cannot be part of the generated model, as we require consistency of the model with the given samples. When testing the negative samples, we cannot reject the constraints if they do not reject the sample, but we can see if a constraint rejects at least some negative samples. If it does not, it seems too weak to be included in the model. In our running example we first check which constraints hold over the complete list of all variables. Thealldifferentconstraint for example does not hold, as the values 0 and 1 are used multiple times. But the constraintnvalue([x 1,1 ,...x 6,10 ],2) holds for a count argument of 2. We add the constraint pattern⟨All,x,id,nvalue(2)⟩to our candidate constraint pattern set. When testing the rows of the matrix, we again see that the constraint alldifferent does not hold, but the conjunction ∀ i∈1..6 sum([x i,1 ,...,x i,10 ], 5) H. Simonis9 holds with the same value 5 for each row. We therefore remember the constraint candidate ⟨EachRow,x,id,sum(5)⟩as well. Checking the columns, we find anothersumconstraint, and checking two rows at the same time, we find that ascalar_productconstraint holds with a value of 2. This constraint works for the patternsConsecutiveRow,OrderedRows andDifferentRows, so we keep the constraints for each of those patterns. There are many other constraint candidates that are detected, for example thenotallequalconstraint that holds for each row and column, as well as for the complete set of variables. The output of this pattern check is a list of all candidate constraint patterns (tuples of pattern, variable, transformations, constraints) that form the model for a given problem instance. Note that at this point we have not yet tried to reduce the set of candidate constraints by subsumption checks or constraint ranking, we also have not yet used the negative examples. 4.1.5 Checker An important component of the tool is a generalized constraint checker, which applies a combination of pattern, variable, transformation and a set of constraints to a set of samples, and which checks if the constraints are satisfied. This checker relies on an implementation of a checker for each global constraint that is modelled. The Global Constraint Catalog provides such checkers for most constraints, but, as we are using a different implementation language, we had to reimplement these checkers for each constraint. 4.2 Generalizing Models The next stage of the process is to combine the models created for each problem instance into a generic model, this faces three challenges: The generic model should only contain constraints that are found in all of the specific models. In order to be transferable, we have to be able to find all parameter values either directly in the input data, or derive them by some formula from given parameter values. We want to produce a minimal model, and should therefore remove all constraints that are either subsumed by stronger constraints, or that do not contribute to the propagation. These concerns are handled by the following components. 4.2.1 Generalizer By defining a constraint pattern based on structural conditions (e.g. each row of a matrix), instead of numerical parameters, like in ModelSeeker, we can generalize a constraint easily by checking if the same constraint, pattern, and transformation occurs in each instance model. By not performing the subsumption checks already on each instance model, we find all constraints that hold in the generic model without having to consider subsumption rules between them. In our example, we see that the candidate⟨EachRow,x,id,sum(.)⟩is present in each of our instance models, albeit with a different parameter value for the sum. We therefore add this constraint pattern to our generic model. In same same way, we find that asum constraint over each column, and thescalar_productconstraint are part of the generic model. Constraint patterns that are only in some, but not all, of our instance models are not part of the generic model. 10Learning Size Independent Constraint Models 4.2.2 Formula Generator When we generalize the size specific models, we find that different parameter values are used for the size of lists and matrices the domain bounds of the different sets of variables constraint parameter values To complete our generic model, we have to explain each such parameter in terms of given input data. Figure 4 shows an example for our running example, with each line showing on the left the given parameters of the instance, and on the right, the parameter values used in the models. The first line corresponds to the instances of Table 1. In order to characterize these parameters, we differentiate five cases: If the parameter uses a constant value in every model, then we just use that fixed value. In our example, the domains of the decision variables are always fixed to 0 and 1, shown in blue. If the parameter value used is equal to one of the given input parameters, we use that parameter to explain the value. In Figure 4 three parameters (shown in green) use the input parameters directly. As a slight generalization, we consider a set of 20 primitive, one argument functions like npairs(x) :=x(x−1)/2 , and check if these functions explain the observed values. None of these functions directly explain the missing cases in our example. Finally, we allow nested, complex functions of the formf 1 opf 2 with the usual operators op ∈ +,−,∗,/of increasing sizek, where eachf i is either a primitive function or a complex formula of smaller size. Two such formulas of size 3, shown at the bottom of Figure 4, are needed in our example, one for the number of columns of the matrix, the other to define the row sum value (both in red). If none of the methods above explains some parameter value, we ask the user for help. The generated program is incomplete, but the user can substitute their own formula to overcome this problem. This brute force, bottom up approach to parameter discovery is very simple, but suffices to find parameter formulas in all given benchmark cases in a few (milli)seconds. More complex equation discovery methods, as for example described in [38], can be added for more difficult cases in the future. Figure 4 Input Samples for Formula Generator Input ParametersVariable DefinitionSymbolic Values λ v kdomain rows columns rowsum colsum scalarproduct 2630..1610532 1730..177331 4630..16201034 1930..1912431 2730..1714632 3840..1814743 columns = λ∗ npairs(v) npairs(k) = λ∗ v(v− 1) k(k− 1) rowsum = λ(v− 1) k− 1 H. Simonis11 4.2.3 Model Reduction Once we have identified all possible candidate constraint patterns for the generic model, we can perform a model reduction to eliminate unneeded constraints. This reuses the methodology developed for ModelSeeker, using subsumption, contractible and extensible information in the catalog linking different constraints. We for example remove thenvalue(2)constraint over all variables, as it is implied by the domain 0..1. We also only keep thescalar_product constraint for theAllDifferenentRowspattern, as the constraints for the patterns AllConsecutiveRows and AllOrderedRows are subsumed. In addition, we perform a ranking of the constraints to eliminate unlikely model elements. For example, thenotallequalconstraint over the complete variable set holds in the majority of models, but it is rarely of interest, as it rejects only a minuscule number of possible assignments. On the other hand, we should not reject the constraint altogether. If no other promising constraints are found, and the constraint applies to a smaller subset of the variables, it can be useful in a model. In the benchmark set, one such situation occurs for problem type 07, Schur’s Lemma. Figure 5 shows a graphical representation of the generic model found for our running example. The model is based on a single matrix (in blue) of 0/1 variables withvrows and cf1 columns, we don’t use any transformation in this model, and five types of constraints are recognized. Each constraint (in yellow) is represented as a box with a number of ports representing its arguments. There is asumconstraint that applies for each row of the matrix (pattern shown in magenta), with the total given by formula (formulas shown in green)cf3, anothersumover all columns equal tok, thescalar_productof different rows which is equal toλ, and two symmetry breaking constraints for the problem, that were found since the samples given did satisfy these constraints. If the problem generator did not use those constraints, we would not identify them for the given problem. This graphical representation is a compact way to show the complete model, and could be used as well by the user to add or remove constraints to a model in a system independent way. A formulacf2 was introduced to explain the total number of ones in the matrix, but the corresponding constraint was eliminated in the model reduction. Figure 5 Graph Representation of Generic Model x[1..v,1..cf1]::0..1 AllRows AllColumns DifferentRows Matrix MatrixTransposed sum sum scalar_product lex_greater lex_geq cf3 := λ∗ (v− 1)/(k− 1) k λ cf1 := λ∗ p(v)/p(k) 12Learning Size Independent Constraint Models Figure 6 Generated MiniZinc Code for Example 1 % Generated Constraint Model for Problem type12 2 % Produced by . . . 3 include " globals . mzn" ; 4 include " . . / m inizi ncli brary / cat . mzn" ; 5 6 % Integer Parameters 7 int : k ; % inputData : k 8 int : lambda ; % inputData : lambda 9 int : v ; % inputData : v 10 11 % Generic Formulas 12 int : cf 1 = lambda∗ npairs (v) div npairs (k) ; 13 int : cf 2 = 2∗lambda∗ npairs (v) div nminus1 (k) ; 14 int : cf 3 = lambda∗nminus1 (v) div nminus1 (k) ; 15 % Variables 16 array [ 1 . . v , 1 . . cf 1 ] of var 0 . . 1 : x ; % matrix 17 18 % Constraints 19 % Constraint 1 20 constraint lex_chain_greater (x) ; 21 % Constraint 4 22 constraint lex_chain_greatereq ( transpose (x) ) ; 23 % Constraint 5 24 constraint f o r a l l ( i in 1 . . v) 25 (sum ( [ x [ i , j ] | j in 1 . . cf 1 ] )=cf 3 ) ; 26 % Constraint 6 27 constraint f o r a l l ( j in 1 . . cf 1 ) 28 (sum ( [ x [ i , j ] | i in 1 . . v ] )=k) ; 29 % Constraint 7 30 constraint f o r a l l ( i 1 , i 2 in 1 . . v where i 1 != i 2 ) 31 ( scalarproduct ( [ x [ i 1 , j ] | j in 1 . . cf 1 ] , [ x [ i 2 , j ] | j in 1 . . cf 1 ] , lambda ) ) ; 32 33 % Objective 34 solve s a t i s f y ; 4.3 Producing Working CP Program The final block of the system is concerned with generating a working constraint program from the generic model, and providing enough information to the user to explain the model and its constraints. 4.3.1 Code Generator This major element is code generation, which produces MniZinc code from the generic model. As the MiniZinc version used was not able to read the JSON input data directly, an additional small module was required to transform the given input data in JSON format into an equivalent representation as .dzn files. The code generation itself relies on a library file, which provides implementations of some of the global constraints that are not currently available in MiniZinc directly, and which also provides the primitive functions used in Section 4.2.2 to define new parameters of the system. The code generation is then quite straightforward, first defining the input data used, any computed parameter values, then the definition of the variables used in the system, followed by the constraints that have been selected. Finally, a default search for a feasible solution is specified. If an objective function has been detected, a search for an optimal solution can the given instead. Note that we use generic names for the variables, to avoid name-clashes with reserved words in MiniZinc. Figure 6 shows the generated code for the running example. For this specific example, we find the three input parameters (v, k, lambda), three dependent parameters (cf1, cf2, cf3), a matrix of 0/1 decision variablesx, and the selected constraints of the system. Each selection H. Simonis13 pattern (EachRow, etc) corresponds to a selection mechanism that identifies which variables are in scope of the constraints. 4.3.2 Description Generator The second output of the generator phase is a textual description of the constraint model, as given for our running example in Figure 7. While the inverse problem of extracting a constraint model from an arbitrary textual description is difficult [19], we can generate a basic description with a simple, template-based format. Note that more detailed natural language descriptions of the global constraints should be added, we currently only handle some specific constraints with individual templates. An interesting direction for future research would be to adapt the description to specific problem domains, e.g. describe a model as a scheduling problem if we find the relevant structure. Figure 7 Generated Description Given integer parameters k, lambda, and v, and introducing symbols cf1 = lambda*npairs(v) div npairs(k) cf3 = lambda*nminus1(v) div nminus1(k) find an assignment for a matrix x with v rows and cf1 columns, where each element ranges between 0 and 1, such that 1 the constraint lexchaingreater(x) holds for the matrix x. 4 the constraint lexchaingeq(transpose(x)) holds for the transposed matrix x. 5 the sum of each row of x is equal to cf3. 6 the sum of each column of x is equal to k. 7 the scalar product of every pair of different rows of x is equal to lambda. 4.3.3 Report Generator In some cases, a user may be satisfied with only the generated code and description, but a lot more information about the acquisition process is available. We therefore generate a report that documents the different steps of the process, and that shows which information was extracted, and which choices were made. It lists the constraints found, showing which constraints were rejected either by subsumption, or low ranking, and which formulas were generated from the given data. 5 Evaluation We have evaluated our system on the benchmark problems defined for the PTHG21 Chal- lenge [40]. This dataset provides 15 problem, for which multiple instances are considered. For each instance, solutions and non-solutions are provided. The number of solutions given varies widely, some problems only have a single solution, for others only a fraction of all possible solutions are given. In addition to the given samples, the data also provide test cases of known and unknown sizes which the system needs to classify as solutions or non-solutions. Finally, the participants can enter new solutions found, which are not covered by the given samples or tests, to show that their system can generate previously unseen solutions. The overall test score is a combination of the number of tests labelled correctly, and the number and correctness of any extra solutions provided. 14Learning Size Independent Constraint Models Table 2 lists the problems in the benchmark set, a large number are taken from CSPlib, and some variations of well-known puzzles are included. Different problems test specific aspects of the acquisition challenge, like structured solutions, input data, or implicit variables not presented in the given samples. Table 2 PTHG21 Problems TypeProblemSourceFeatures 1Graph ColoringALICE, CHIPgraph as data, optimization 2N-QueensCSPlib 054 3Warehouse LocationCSPlib 034cost matrix/vector as data, implicit cost variables 4Golomb RulerCSPlib 006implicit decision variables, optimization 5SudokuPre-assignmentpre-assignment as data, single solution 6Sudoku No pre-assignmentmany solutions 7Schur’s LemmaCSPlib 015non-standard variable pattern, ternary constraint 8All IntervalCSPlib 007auxiliary variables 10Magic SquaresCSPlib 019implicit formula 11 Orthogonal Latin SquaresEulerconstraint on tuples 12BIBDCSPlib 028 3 parameters, implicit formulas, symmetry breaking 13Costas ArrayCSPlib 076auxiliary variables, constraint on tuples 14N-Queens variantfairy chess piecenon-traditional attack 15N-Queens variant 16N-Queens variant Table 3 shows the results of testing our system with the dataset. The generic models that we generated are accepting all positive examples, and rejecting all negative examples, showing that the constraints generated are flexible enough to deal with the models encountered. When testing the system against the classification data, we achieve 100% accuracy, indicating that the models generalize the problem correctly. This does not mean that the generated code matches the original problems perfectly. When we try generate extra solution from the models we encounter two problems: 1. For the Golomb ruler problem the upper bound of the domain is the value of the optimal solution. We are not able to find a generic formula that predicts the value of the optimal solution for a new problem size (this is unlikely to exist in a simple closed form), so that we cannot generate extra solutions for unknown problem sizes. We might call this an issue with the given problem statement. 2.For problem 16, we find most, but not all constraints of an extended n-queen type puzzle, where the pieces can also attack each other in repeated knight’s moves. This constraint cannot be expressed by the current patterns that we consider. When generating new solutions, we miss this constraint, and most of the generated solutions are rejected. By chance, the constraints are not required to decide the test cases, so our model still labels all tests correctly. This highlights that our method (like all passive acquisition methods) heavily depends on the quality of the sample solutions and non solutions to identify the intended model. For two of the benchmarks (Sudoku and Schur’s Lemma), there are no extra solutions that can be found, as the number of solutions is limited. The total time to acquire and generate all benchmark problems was 10 minutes, using a single core on a laptop. This includes the time required to classify the test cases. Each run of the generated model for a given instance to generate extra solutions was limited to 300 seconds. We note that the generated programs for all problems can be run with at least one of the MiniZinc back-end solvers, producing initial solutions in seconds. For some problems, not all solutions could be generated within a 300 second timeout, either because there are too many solutions to enumerate, or the solver backtracks deeply after finding initial solutions. The generated code is in most, but not all case comparable to a handwritten model of H. Simonis15 Table 3 Results on PTHG21 Benchmarks Classified Correctly Problem DescriptionInstances Positive Samples Negative SamplesTests Extra Solutions Note 1Graph Coloring10100.00100.00100.00 2N-Queens10100.00100.00100.00 3Warehouse Location10100.00100.00100.00 4Golomb Ruler8100.00100.00100.001 5Sudoku (with Hints)10 100.00100.00100.00 6Sudoku (without Hints)4100.00100.00100.00 7Schur’s Lemma13100.00100.00100.00 8All Interval10100.00100.00100.00 10Magic Squares6100.00100.00100.00 11Orthogonal Latin Squares2100.00100.00100.00 12BIBD20100.00100.00100.00 13Costas Array11100.00100.00100.00 14N-Queens Variant11100.00100.00100.00 15N-Queens Variant7100.00100.00100.00 16N-Queens Variant13100.00100.00100.002 the problem based on the same decision variables. For the Costas Array problem (problem 13) the generated model using a more elegantlexdifferentconstraint on difference tuples, while the handwritten models we have seen decompose this constraint into multiple alldifferent constraints. 6 Conclusions and Future Work While the results of the system are very encouraging, there are a number of fundamental problems that need to be addressed before it can become an operational tool for acquiring constraints model for typical applications. optimization problemsWith our current approach we can identify typical objective functions, but at this point we do not handle cases where only optimal (or near optimal) solutions are accepted. index setsThe current support for index sets is limited. We should add more complicated index filtering which depends on input data, for example selecting all tasks whose duration exceeds a parameter value. large input datasets In many practical problems, we are not just given the required input data, but many other items and tables that are not relevant to the solution process. Identifying which parts of the input data are needed to define the model is a major research challenge. unknown constraintsThe system relies on the global constraint catalog to provide a wide variety of global constraints that can be used to model the problem. If we are given a new problem that requires some new global constraint not currently described in the catalog and modelled in our system, we will only be able to partially model the problem. user interactionOur current evaluation focusses on an automated acquisition process, where the role of the user is quite limited. We should investigate how the user can interact with a system to help with the acquisition process, providing useful information while avoiding asking too many or too repetitive questions. Overall, the system described shows the feasibility of dealing with a more realistic use case for constraint acquisition, indicating that more powerful modelling tools for dealing with real world problem types and sizes are possible. 16Learning Size Independent Constraint Models References 1 Hajar Ait Addi, Christian Bessiere, Redouane Ezzahir, and Nadjib Lazaar. Time-bounded query generator for constraint acquisition. In Willem Jan van Hoeve, editor, Integration of Constraint Programming, Artificial Intelligence, and Operations Research - 15th International Conference, CPAIOR 2018, Delft, The Netherlands, June 26-29, 2018, Proceedings, volume 10848 of Lecture Notes in Computer Science, pages 1–17. Springer, 2018.doi:10.1007/ 978-3-319-93031-2\_1. 2Ekaterina Arafailova, Nicolas Beldiceanu, Rémi Douence, Mats Carlsson, Pierre Flener, María Andreína Francisco Rodríguez, Justin Pearson, and Helmut Simonis. Global constraint catalog, volume i, time-series constraints. CoRR, abs/1609.08925, 2016. URL:http://arxiv.org/ abs/1609.08925, arXiv:1609.08925. 3Robin Arcangioli, Christian Bessiere, and Nadjib Lazaar. Multiple constraint acquisition. In Subbarao Kambhampati, editor, Proceedings of the Twenty-Fifth International Joint Conference on Artificial Intelligence, IJCAI 2016, New York, NY, USA, 9-15 July 2016, pages 698–704. IJCAI/AAAI Press, 2016. URL: http://w.ijcai.org/Abstract/16/105. 4N. Beldiceanu and H. Simonis. Using the global constraint seeker for learning structured constraint models: a first attempt. In The 10th International Workshop on Constraint Modelling and Reformulation (ModRef 2011), pages 20–34, Perugia, Italy, September 2011. 5Nicolas Beldiceanu, Mats Carlsson, and Jean-Xavier Rampon. Global constraint catalog. Technical report, Swedish Institute of Computer Science, 2012. 6Nicolas Beldiceanu, Georgiana Ifrim, Arnaud Lenoir, and Helmut Simonis. Describing and generating solutions for the EDF unit commitment problem with the ModelSeeker. In Christian Schulte, editor, Principles and Practice of Constraint Programming - 19th International Conference, CP 2013, Uppsala, Sweden, September 16-20, 2013. Proceedings, volume 8124 of Lecture Notes in Computer Science, pages 733–748. Springer, 2013.doi:10.1007/ 978-3-642-40627-0\_54. 7Nicolas Beldiceanu and Helmut Simonis. A Model Seeker: Extracting global constraint models from positive examples. In Michela Milano, editor, Principles and Practice of Constraint Programming - 18th International Conference, CP 2012, Québec City, QC, Canada, October 8-12, 2012. Proceedings, volume 7514 of Lecture Notes in Computer Science, pages 141–157. Springer, 2012. doi:10.1007/978-3-642-33558-7\_13. 8Christian Bessiere, Clément Carbonnel, Anton Dries, Emmanuel Hebrard, George Katsirelos, Nadjib Lazaar, Nina Narodytska, Claude-Guy Quimper, Kostas Stergiou, Dimosthenis C. Tsouros, and Toby Walsh. Partial queries for constraint acquisition. CoRR, abs/2003.06649, 2020. URL: https://arxiv.org/abs/2003.06649, arXiv:2003.06649. 9Christian Bessiere, Remi Coletta, Abderrazak Daoudi, Nadjib Lazaar, Younes Mechqrane, and El-Houssine Bouyakhf. Boosting constraint acquisition via generalization queries. In Torsten Schaub, Gerhard Friedrich, and Barry O’Sullivan, editors, ECAI 2014 - 21st European Conference on Artificial Intelligence, 18-22 August 2014, Prague, Czech Republic - Including Prestigious Applications of Intelligent Systems (PAIS 2014), volume 263 of Frontiers in Artificial Intelligence and Applications, pages 99–104. IOS Press, 2014.doi:10.3233/ 978-1-61499-419-0-99. 10 Christian Bessiere, Remi Coletta, Eugene C. Freuder, and Barry O’Sullivan. Leveraging the learning power of examples in automated constraint acquisition. In Mark Wallace, editor, Principles and Practice of Constraint Programming - CP 2004, 10th International Conference, CP 2004, Toronto, Canada, September 27 - October 1, 2004, Proceedings, volume 3258 of Lecture Notes in Computer Science, pages 123–137. Springer, 2004.doi:10.1007/ 978-3-540-30201-8\_12. 11Christian Bessiere, Remi Coletta, Emmanuel Hebrard, George Katsirelos, Nadjib Lazaar, Nina Narodytska, Claude-Guy Quimper, and Toby Walsh. Constraint acquisition via partial queries. In Francesca Rossi, editor, IJCAI 2013, Proceedings of the 23rd International Joint Conference H. Simonis17 on Artificial Intelligence, Beijing, China, August 3-9, 2013, pages 475–481. IJCAI/AAAI, 2013. URL: http://w.aaai.org/ocs/index.php/IJCAI/IJCAI13/paper/view/6659. 12Christian Bessiere, Remi Coletta, Barry O’Sullivan, and Mathias Paulin. Query-driven constraint acquisition. In Manuela M. Veloso, editor, IJCAI 2007, Proceedings of the 20th International Joint Conference on Artificial Intelligence, Hyderabad, India, January 6-12, 2007, pages 50–55, 2007. URL:http://ijcai.org/Proceedings/07/Papers/006.pdf. 13Christian Bessiere, Abderrazak Daoudi, Emmanuel Hebrard, George Katsirelos, Nadjib Lazaar, Younes Mechqrane, Nina Narodytska, Claude-Guy Quimper, and Toby Walsh. New approaches to constraint acquisition. In Christian Bessiere, Luc De Raedt, Lars Kotthoff, Siegfried Nijssen, Barry O’Sullivan, and Dino Pedreschi, editors, Data Mining and Constraint Programming - Foundations of a Cross-Disciplinary Approach, volume 10101 of Lecture Notes in Computer Science, pages 51–76. Springer, 2016. doi:10.1007/978-3-319-50137-6\_3. 14Christian Bessiere, Frédéric Koriche, Nadjib Lazaar, and Barry O’Sullivan. Constraint acquisition. Artif. Intell., 244:315–342, 2017. doi:10.1016/j.artint.2015.08.001. 15 Dirko Coetsee, Steve Kroon, McElory Hoffmann, and Luc De Raedt. Splyci: Integrating spreadsheets by recognising and solving layout constraints. In Pedro Henriques Abreu, Pedro Pereira Rodrigues, Alberto Fernández, and João Gama, editors, Advances in Intelligent Data Analysis XIX - 19th International Symposium on Intelligent Data Analysis, IDA 2021, Porto, Portugal, April 26-28, 2021, Proceedings, volume 12695 of Lecture Notes in Computer Science, pages 402–413. Springer, 2021. doi:10.1007/978-3-030-74251-5\_32. 16 Charles J Colbourn. CRC handbook of combinatorial designs. CRC press, 1996. 17Remi Coletta, Christian Bessière, Barry O’Sullivan, Eugene C. Freuder, Sarah O’Connell, and Joël Quinqueton. Semi-automatic modeling by constraint acquisition. In Francesca Rossi, editor, Principles and Practice of Constraint Programming - CP 2003, 9th International Conference, CP 2003, Kinsale, Ireland, September 29 - October 3, 2003, Proceedings, volume 2833 of Lecture Notes in Computer Science, pages 812–816. Springer, 2003.doi:10.1007/ 978-3-540-45193-8\_58. 18 Eugene C. Freuder. Constraint acquisition. In Jacques Calmet, Belaid Benhamou, Olga Caprotti, Laurent Henocque, and Volker Sorge, editors, Artificial Intelligence, Automated Reasoning, and Symbolic Computation, Joint International Conferences, AISC 2002 and Calculemus 2002, Marseille, France, July 1-5, 2002, Proceedings, volume 2385 of Lecture Notes in Computer Science, page 1. Springer, 2002. doi:10.1007/3-540-45470-5\_1. 19 Zeynep Kiziltan, Marco Lippi, and Paolo Torroni. Constraint detection in natural language problem descriptions. In Subbarao Kambhampati, editor, Proceedings of the Twenty-Fifth International Joint Conference on Artificial Intelligence, IJCAI 2016, New York, NY, USA, 9-15 July 2016, pages 744–750. IJCAI/AAAI Press, 2016. URL:http://w.ijcai.org/ Abstract/16/111. 20 Samuel Kolb, Sergey Paramonov, Tias Guns, and Luc De Raedt. Learning constraints in spreadsheets and tabular data. Mach. Learn., 106(9-10):1441–1468, 2017.doi:10.1007/ s10994-017-5640-x. 21Samuel Kolb, Stefano Teso, Andrea Passerini, and Luc De Raedt. Learning SMT(LRA) constraints using SMT solvers. In Jérôme Lang, editor, Proceedings of the Twenty-Seventh International Joint Conference on Artificial Intelligence, IJCAI 2018, July 13-19, 2018, Stockholm, Sweden, pages 2333–2340. ijcai.org, 2018. doi:10.24963/ijcai.2018/323. 22Mohit Kumar, Samuel Kolb, Clément Gautrais, and Luc De Raedt. Democratizing constraint satisfaction problems through machine learning. In Thirty-Fifth AAAI Conference on Artificial Intelligence, AAAI 2021, Thirty-Third Conference on Innovative Applications of Artificial Intelligence, IAAI 2021, The Eleventh Symposium on Educational Advances in Artificial Intelligence, EAAI 2021, Virtual Event, February 2-9, 2021, pages 16057–16059. AAAI Press, 2021. URL: https://ojs.aaai.org/index.php/AAAI/article/view/18011. 23 Mohit Kumar, Samuel Kolb, Stefano Teso, and Luc De Raedt. Learning MAX-SAT from contextual examples for combinatorial optimisation. In The Thirty-Fourth AAAI Conference 18Learning Size Independent Constraint Models on Artificial Intelligence, AAAI 2020, The Thirty-Second Innovative Applications of Artificial Intelligence Conference, IAAI 2020, The Tenth AAAI Symposium on Educational Advances in Artificial Intelligence, EAAI 2020, New York, NY, USA, February 7-12, 2020, pages 4493–4500. AAAI Press, 2020. URL:https://aaai.org/ojs/index.php/AAAI/article/view/ 5877. 24Mohit Kumar, Stefano Teso, Patrick De Causmaecker, and Luc De Raedt. Automating personnel rostering by learning constraints using tensors. In 31st IEEE International Conference on Tools with Artificial Intelligence, ICTAI 2019, Portland, OR, USA, November 4-6, 2019, pages 697–704. IEEE, 2019. doi:10.1109/ICTAI.2019.00102. 25 Mohit Kumar, Stefano Teso, and Luc De Raedt. Acquiring integer programs from data. In Sarit Kraus, editor, Proceedings of the Twenty-Eighth International Joint Conference on Artificial Intelligence, IJCAI 2019, Macao, China, August 10-16, 2019, pages 1130–1136. ijcai.org, 2019. doi:10.24963/ijcai.2019/158. 26Arnaud Lallouet, Matthieu Lopez, Lionel Martin, and Christel Vrain. On learning constraint problems. In 22nd IEEE International Conference on Tools with Artificial Intelligence, ICTAI 2010, Arras, France, 27-29 October 2010 - Volume 1, pages 45–52. IEEE Computer Society, 2010. doi:10.1109/ICTAI.2010.16. 27 Nicholas Nethercote, Peter J. Stuckey, Ralph Becket, Sebastian Brand, Gregory J. Duck, and Guido Tack. Minizinc: Towards a standard CP modelling language. In Christian Bessiere, editor, Principles and Practice of Constraint Programming - CP 2007, 13th International Conference, CP 2007, Providence, RI, USA, September 23-27, 2007, Proceedings, volume 4741 of Lecture Notes in Computer Science, pages 529–543. Springer, 2007.doi:10.1007/ 978-3-540-74970-7\_38. 28Sergey Paramonov, Samuel Kolb, Tias Guns, and Luc De Raedt. Tacle: Learning constraints in tabular data. In Ee-Peng Lim, Marianne Winslett, Mark Sanderson, Ada Wai-Chee Fu, Jimeng Sun, J. Shane Culpepper, Eric Lo, Joyce C. Ho, Debora Donato, Rakesh Agrawal, Yu Zheng, Carlos Castillo, Aixin Sun, Vincent S. Tseng, and Chenliang Li, editors, Proceedings of the 2017 ACM on Conference on Information and Knowledge Management, CIKM 2017, Singapore, November 06 - 10, 2017, pages 2511–2514. ACM, 2017. doi:10.1145/3132847.3133193. 29Tomasz P. Pawlak and Krzysztof Krawiec. Automatic synthesis of constraints from examples using mixed integer linear programming. Eur. J. Oper. Res., 261(3):1141–1157, 2017.doi: 10.1016/j.ejor.2017.02.034. 30Tomasz P. Pawlak and Krzysztof Krawiec. Synthesis of constraints for mathematical program- ming with one-class genetic programming. IEEE Trans. Evol. Comput., 23(1):117–129, 2019. doi:10.1109/TEVC.2018.2835565. 31Tomasz P. Pawlak and Bartosz Litwiniuk. Ellipsoidal one-class constraint acquisition for quadratically constrained programming. Eur. J. Oper. Res., 293(1):36–49, 2021.doi: 10.1016/j.ejor.2020.12.018. 32Steve Prestwich. Robust constraint acquisition by sequential analysis. In Giuseppe De Giacomo, Alejandro Catalá, Bistra Dilkina, Michela Milano, Senén Barro, Alberto Bugarín, and Jérôme Lang, editors, ECAI 2020 - 24th European Conference on Artificial Intelligence, 29 August-8 September 2020, Santiago de Compostela, Spain, August 29 - September 8, 2020 - Including 10th Conference on Prestigious Applications of Artificial Intelligence (PAIS 2020), volume 325 of Frontiers in Artificial Intelligence and Applications, pages 355–362. IOS Press, 2020. doi:10.3233/FAIA200113. 33 Steven Prestwich. CSPLib problem 028: Balanced incomplete block designs.http://w. csplib.org/Problems/prob028. 34Steven D. Prestwich. Unsupervised constraint acquisition. In 33rd IEEE International Conference on Tools with Artificial Intelligence, ICTAI 2021, Washington, DC, USA, November 1-3, 2021, pages 256–262. IEEE, 2021. doi:10.1109/ICTAI52525.2021.00042. H. Simonis19 35 Steven D. Prestwich, Eugene C. Freuder, Barry O’Sullivan, and David Browne. Classifier- based constraint acquisition. Ann. Math. Artif. Intell., 89(7):655–674, 2021.doi:10.1007/ s10472-021-09736-4. 36 Steven D. Prestwich, Brahim Hnich, Helmut Simonis, Roberto Rossi, and S. Armagan Tarim. Partial symmetry breaking by local search in the group. Constraints An Int. J., 17(2):148–171, 2012. doi:10.1007/s10601-012-9117-z. 37Luc De Raedt, Anton Dries, Tias Guns, and Christian Bessiere. Learning constraint satisfaction problems: An ILP perspective. In Christian Bessiere, Luc De Raedt, Lars Kotthoff, Siegfried Nijssen, Barry O’Sullivan, and Dino Pedreschi, editors, Data Mining and Constraint Pro- gramming - Foundations of a Cross-Disciplinary Approach, volume 10101 of Lecture Notes in Computer Science, pages 96–112. Springer, 2016.doi:10.1007/978-3-319-50137-6\_5. 38Naina Razakarison, Mats Carlsson, Nicolas Beldiceanu, and Helmut Simonis. GAC for a linear inequality and an atleast constraint with an application to learning simple polynomials. In Malte Helmert and Gabriele Röger, editors, Proceedings of the Sixth Annual Symposium on Combinat- orial Search, SOCS 2013, Leavenworth, Washington, USA, July 11-13, 2013. AAAI Press, 2013. URL: http://w.aaai.org/ocs/index.php/SOCS/SOCS13/paper/view/7215. 39 Arik Senderovich, Kyle E. C. Booth, and J. Christopher Beck. Learning scheduling models from event data. In J. Benton, Nir Lipovetzky, Eva Onaindia, David E. Smith, and Siddharth Srivastava, editors, Proceedings of the Twenty-Ninth International Conference on Automated Planning and Scheduling, ICAPS 2018, Berkeley, CA, USA, July 11-15, 2019, pages 401–409. AAAI Press, 2019. URL:https://aaai.org/ojs/index.php/ICAPS/article/view/ 3504. 40 Helmut Simonis and Eugene Freuder. PTHG21 challenge, August 2021. The results of the Challenge were presented at the PTHG21 workshop of CP 2021. videos of the presentations are in the youtube playlist athttps://w.youtube.com/playlist? list=PL97NT99ttj2AAQh9_KxxEGVBA_X79pVhD (videos 8-11).doi:10.5281/zenodo. 5155465. 41Dimosthenis C. Tsouros and Kostas Stergiou. Efficient multiple constraint acquisition. Con- straints An Int. J., 25(3-4):180–225, 2020. doi:10.1007/s10601-020-09311-4. 42Dimosthenis C. Tsouros and Kostas Stergiou. Learning max-csps via active constraint acquisi- tion. In Laurent D. Michel, editor, 27th International Conference on Principles and Practice of Constraint Programming, CP 2021, Montpellier, France (Virtual Conference), October 25-29, 2021, volume 210 of LIPIcs, pages 54:1–54:18. Schloss Dagstuhl - Leibniz-Zentrum für Informatik, 2021. doi:10.4230/LIPIcs.CP.2021.54. 43 Dimosthenis C. Tsouros, Kostas Stergiou, and Christian Bessiere. Structure-driven multiple constraint acquisition. In Thomas Schiex and Simon de Givry, editors, Principles and Practice of Constraint Programming - 25th International Conference, CP 2019, Stamford, CT, USA, September 30 - October 4, 2019, Proceedings, volume 11802 of Lecture Notes in Computer Science, pages 709–725. Springer, 2019. doi:10.1007/978-3-030-30048-7\_41. 44 Dimosthenis C. Tsouros, Kostas Stergiou, and Christian Bessiere. Omissions in constraint acquisition. In Helmut Simonis, editor, Principles and Practice of Constraint Programming - 26th International Conference, CP 2020, Louvain-la-Neuve, Belgium, September 7-11, 2020, Proceedings, volume 12333 of Lecture Notes in Computer Science, pages 935–951. Springer, 2020. doi:10.1007/978-3-030-58475-7\_54.