Hello!
I'm working on a primitive, domain specific saturation engine
prototype.
It's basically about S = (S^C) v (S^!C): try both choices in a
distributable search node, and constrain the domains in the original
to be the disjunctions of the alternatives after propagation.
Sounds easy, but you need completely different distribution
constraints for effective saturation and for effective search.
(My search alternatives come from a heuristic in the form of X=:V []
X\=:V, while my saturation alternatives are bools from FD.disjointC,
for example)
I had to create a protocol over the {Space.ask alternatives (N)} /
{Space.commit M}interface:
choices 1 and 2: regular distribution choices
choices 3 and 4: Symetric, high-impact saturation choices
choice 5: signals that a Space.tell happened, the distributor must
wait for stability again and possibly recalculate statistics for
heuristics.
I think this is ugly.
Would it be possible to pass something a little more complex than an
integer in Space.commit, or at least something a little more
descriptive about the choices than their cardinality in Space.ask?
Or somewhere like Space.chooseSmart and Space.askTotallyVerbose ?
Alternatively, I'd be glad to study any other distributor/search
engine design based on {Space.Tell}s and maybe ports if someone could
give me an example.
Thanks again:
Gabor Szokoli
-
Please send submissions to users@mozart-oz.org
and administriva mail to users-request@mozart-oz.org.
The Mozart Oz web site is at http://www.mozart-oz.org/.