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
_________________________________________________________________________________
mozart-users mailing list
[email protected]
http://www.mozart-oz.org/mailman/listinfo/mozart-users
