bug in FS.reified.include

[Ralph Debusmann]

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