monitor_changes_arr(VarArr, 8, [min of fd, max of fd], fd, Stream)
will monitor the variables in VarArr for modifications of their min/max
fd-attributes. The monitor will run with a priority of 8 to 9.
All variable modifications that occur between two wakings of the
monitor will be detected by the monitor. It will then create a list
of indices of the modified variables, and append this list to
ChangeStream.
[eclipse 4]: X1::1..9, X2::1..8,
monitor_changes_arr(v(X1,X2), 8,
[min of fd, max of fd], fd, Changes),
X1 #> X2, X2 #>= 5.
Changes = [[1], [2, 1]|More]
X1 = X1{[6..9]}
X2 = X2{[5..8]}
What happened here is that the first constraint X1 #> X2 caused X1 to
change its lower bound, therefore [1] was appended to the Changes list.
Then X2 #>= 5 raised the lower bound of X2 and (because X1 #> X2)
the lower bound of X1, therefore both variable indices [1,2] were
appended to the Changes list.
The priority of the monitor should be set up such that is is lower than the priority of the propagation constraints. In that case, the lists that get appended to ChangeStream represent exactly the set of variables (without duplicates) that were modified by one propagation sequence.
Note that the ChangeStream can be used to trigger actions whenever new changes get appended, for example:
delay report_changes(X) if var(X).
report_changes([]).
report_changes([X|T]) :-
printf("The following variables changed: %Mw%n%b", [X]),
report_changes(T).
[eclipse 11]: X1::1..9, X2::1..8,
monitor_changes_arr(v(X1,X2), 8,
[min of fd, max of fd], fd, Changes),
report_changes(Changes),
X1 #> X2, X2 #>= 5.
The following variables changed: [1]
The following variables changed: [2, 1]
...