4.4.1. Prolog facts describing a constraint
For each global constraint, the electronic version of its description is provided as a Prolog file (see the link “.pl file” at the beginning of the section corresponding to a global constraint). In addition the file “eval.pl” contains a set of shared utilities used for evaluating the constraints. This electronic version was used for generating the LaTeX file of this catalogue, the figures associated with the graph -based description and a filtering algorithm for some of the constraints that use the automaton -based description. Within the electronic version, each constraint is described in terms of meta -data. A typical entry is:
ctr_date(minimum, ['20000128','20030820','20040530',
'20041230','20060811','20090416']).
ctr_origin(minimum, '\\index{CHIP|indexuse}CHIP', []).
ctr_arguments(minimum, ['MIN'-dvar, 'VARIABLES'-collection(var-dvar)]).
ctr_exchangeable(minimum,
[items('VARIABLES',all),
vals(['VARIABLES'^var],int,=\=,all,in),
translate(['MIN','VARIABLES'^var])]).
ctr_synonyms(minimum, [min]).
ctr_restrictions(minimum, [size('VARIABLES') > 0, required('VARIABLES',var)]).
ctr_graph(minimum,
['VARIABLES'],
2,
['CLIQUE'>>collection(variables1,variables2)],
[variables1^key = variables2^key #\/ variables1^var < variables2^var],
['ORDER'(0,'MAXINT',var) = 'MIN'],
[]).
ctr_example(minimum, minimum(2,[[var-3],[var-2],[var-7],[var-2],[var-6]])).
ctr_see_also(minimum,
[link('generalisation', minimum_modulo,
'%e replaced by %e', [variable, variable mod constant]),
link('specialisation', min_n,
'minimum or order %e replaced by absolute minimum', [n]),
link('comparison swapped', maximum, '', []),
link('common keyword', maximum, '%k', ['order constraint']),
link('soft variant', open_minimum, '%k', ['open constraint']),
link('soft variant', minimum_except_0, 'value %e is ignored', [0]),
link('implies', between_min_max, '', []),
link('implies', in, '', []),
link('implied by', and, '', [])]).
ctr_key_words(minimum,['order constraint' ,
'minimum' ,
'maxint' ,
'automaton' ,
'automaton without counters' ,
'reified automaton constraint' ,
'centered cyclic(1) constraint network(1)',
'arc-consistency' ]).
ctr_persons(minimum,['Beldiceanu N.']).
ctr_eval(minimum, [builtin(minimum_b), automaton(minimum_a)]).
minimum_b(MIN, VARIABLES) :-
check_type(dvar, MIN), collection(VARIABLES, [dvar]),
length(VARIABLES, N), N > 0,
get_attr1(VARIABLES, VARS), minimum(MIN, VARS).
minimum_a(MIN, VARIABLES) :- % 0: MIN<VAR, 1: MIN=VAR, 2: MIN>VAR
minimum_signature(VARIABLES, SIGNATURE, MIN),
automaton(SIGNATURE, _, SIGNATURE,
[source(s),sink(t)], [arc(s,0,s),arc(s,1,t),arc(t,1,t),arc(t,0,t)],
[],[],[]).
minimum_signature([], [], _).
minimum_signature([[var-VAR]|VARs], [S|Ss], MIN) :-
S in 0..2,
MIN #< VAR #<=> S #= 0, MIN #= VAR #<=> S #= 1, MIN #> VAR #<=> S #= 2,
minimum_signature(VARs, Ss, MIN).
and consists of the following Prolog facts, where is the name of the constraint under consideration. The facts are organised in the following 15 items:
Items 1, 2, 3, 4, 12 and 13 provide general information about a global constraint,
Items 5, 6 and 7 describe the arguments of a global constraint.
Items 9 and 10 describes the meaning of a global constraint in terms of a graph -based representation.
Item 11 provides a ground instance which holds.
Item 14 gives the list of available evaluators of a global constraint.
Item 15 describes the meaning of a global constraint in terms of a set of first order logic formulae.
Items 1, 2, 6 and 11 are mandatory, while all other items are optional. We now give the different items:
ctr_date
is a list of dates when the description of the constraint was modified.
ctr_origin
is a string denoting the origin of the constraint. is a possibly empty list of constraint names related to the origin of the constraint.
ctr_usual_name
When, for some reason, the constraint name used in the catalogue does not correspond to the usual name of the constraint, provides the usual name of the constraint. This stems from the fact that each entry of the catalogue should have a distinct name. This is for instance the case for the and the constraints which are both usually called .
ctr_synonyms
ctr_types
is a list of elements of the form -, where is the name of a new type and the type itself (usually a collection). Basic and compound data types were respectively introduced in sections 2.1.1 and 2.1.2 on page 2.1.1. This field is only used when we need to declare a new type that will be used for specifying the type of the arguments of the constraint. This is for instance the case when one argument of the constraint is a collection for which the type of one attribute is also a collection. This is for instance the case of the constraint where the unique argument is a collection of ; refers to a new type declared in .
ctr_arguments
ctr_restrictions
ctr_exchangeable
ctr_derived_collections
ctr_graph
is a list of collections used for creating the vertices of the initial graph. This was described at page 2.2.3.1 of Section 2.2.3.1.
is the number of vertices of an arc. Arc arity was explained at page 2.2.3.1 of Section 2.2.3.1.
is a list of arc generators. Arc generators were introduced at page 2.2.3.1 of Section 2.2.3.1.
is a list of arc constraints. Arc constraints were defined in Section 2.2.2.2 on page 2.2.2.2.
is a list of graph properties. Graph properties were described in Section 2.2.2.4 on page 2.2.2.4.
ctr_example
is a list of examples (usually one). Each example corresponds to a ground instance for which the constraint holds.
ctr_see_also
is a list of constraints that are related in some way to the constraint. Each element of the list is a fact of the form , where:
is a semantic link that explains why we refer to . Semantic links were described in Section 2.5 on page 2.5.
is the name of the constraint that is linked to .
is a string providing contextual explanation.
is a list of symbols (e.g., keywords, constraint names, mathematical expressions) that are inserted in .
ctr_key_words
is a list of keywords associated with the constraint. Keywords may be linked to the meaning of the constraint, to a typical pattern where the constraint can be applied or to a specific problem where the constraint is useful. All keywords used in the catalogue are listed in alphabetic order in Section 3.7 on page 3.7. Each keyword has an entry explaining its meaning and providing the list of global constraints using that keyword.
ctr_eval
For many of the constraints of the catalogue one or several evaluators are provided. Each evaluator is explicitly described in by an element of the form , where is the name of the Prolog predicate to call in order to evaluate the constraint,Note that this predicate name should be different from existing SICStus built -ins, and can be one of the following keywords:
when the corresponding evaluator uses a SICStus built -in. This is for instance the case of the constraint.
when the corresponding evaluator reformulates the constraints in terms of a conjunction of constraints of the catalogue and/or in term of a conjunction of reified constraints. This is for instance the case of the constraint.
when the corresponding evaluator is based on an automaton that describes the set of solutions accepted by the constraint. The evaluator corresponds to the Prolog code that creates the signature constraints as well as the automata (usually one) associated with the constraint. A fact of the form automaton/9 lists the states and the transitions of the automata used for describing the set of solutions accepted by the constraint. It follows the description provided in Section 2.3.2 on page 2.3.2. The constraint is an example of constraint for which an automaton is provided.
when the corresponding evaluator is based on a first order logic formula that describes the meaning of the constraint. This is for instance the case of the constraint.
when the corresponding evaluator only accepts ground instances of the constraint. This is for instance the case of the constraint.
ctr_logic
is a list of first order logical formulae that describe the meaning of the constraint [CarlssonBeldiceanuMartin08].