bug in FS.reified.include

[Ralph Debusmann]

Hi once again,

I think I have found the cause of the bug. It is not FS.reified.include 
which is to blame, but a class method more deeply rooted in the Mozart/Oz 
FS-constraint system, namely FSetConstraint::getNotInSet in 
"platform/emulator/fset.cc". Originally, it does the following:

inline
FSetValue FSetConstraint::getNotInSet(void) const
{
#ifdef BIGFSET
   if (_normal)
     return FSetValue(_not_in, _otherout);
   else
     return FSetValue(_OUT);
#else
   return FSetValue(_not_in);
#endif
}

which reads ok at a first glance. Now, I hope to understand the constraint 
system right that a set is "normal" if it has no elements beyond 63 (and 
can hence be more efficiently represented as a bitstring) in its upper 
bound. But this means that the integers not in this set (getNotInSet) 
*must* have elements beyond 63 in its upper bound, and hence, the 
complement must be an "extended" set, and not a "normal" one.

That is, the problem with getNotInSet as it stands in Mozart/Oz 1.3.2
is that it does not update the complement set to "extended", and this is 
what has caused the bug with FS.reified.include discussed earlier in this 
thread. And I suppose this bug has lead to numerous other bugs in the 
constraint system that we don't even know of yet.

Here is the fix: we simply "extend" the FSetValue before we return it:

inline
FSetValue FSetConstraint::getNotInSet(void) const
{
#ifdef BIGFSET
   if (_normal) {
     FSetValue s = FSetValue(_not_in, _otherout);
     s.toExtended();
     return s;
   }
   else
     return FSetValue(_OUT);
#else
   return FSetValue(_not_in);
#endif
}

The fix seems to work, but as I am missing deep knowledge of the deepest 
depths of the Mozart/Oz constraint system, it could still be wrong. And, 
what's worse, it slows down the system a lot :(

Cheers, Ralph