Hi Jorge,
here is some more code demonstrating the bug in FS.reified.include that
you have found:
proc {Test Sol}
M = {FS.value.make [1 2 3]}
D = {FS.reified.include 64 M}
in
Sol = D
end
Sols = {Search.base.all Test}
{Inspect Sols}
Feeding this code does not determine the elements of Sols, but returns
['_'{0#1}]
in the Inspector. When I replace the 64 with 63 in
D = {FS.reified.include 64 M}
Sols does get determined and bound to:
[0]
I do recall that the Mozart FS constraints, when they were first
implemented in the 90s, only worked with values up to 63 - higher values
were introduced later, and there were a number of bugs at the beginning
and much trouble.
Now, I guess, Mozart still works with two internal representations for
sets containing values up to 63 (using bitstrings when I recall correctly)
and sets containing higher values. So the above bug can be "explained" as
follows: when a set with values <64 gets determined, its representation is
changed to bitstrings. Then the call to FS.reified.include ensues where it
is checked whether a number >63 is included in the set M which can
(because of its representation) only contain values up to 63, and here
some kind of clash occurs.
One could fix this by replacing FS.reified.include by the following code:
fun {ReifiedInclude D M}
D1 = {FD.int 0#1}
in
thread
or {FS.include D M}
D1=1
[] {FS.exclude D M}
D1=0
end
end
D1
end
Since FS.include and FS.exclude seem as if they do not have the same bug
as FS.reified.include. However, I sincerely think that someone should
check the Mozart constraint system and fix the bugs within Mozart.
Especially since I have the uneasy feeling that there may be more bugs
like this still hidden in the Mozart constraint engine...
Cheers, Ralph
_________________________________________________________________________________
mozart-users mailing list
[email protected]
http://www.mozart-oz.org/mailman/listinfo/mozart-users
