Oz and Mozart Users Mailing List

Re: Feature request: Limitations of the alternatives() interface


From: Christian Schulte (schulte@imit.kth.se)
Date: Thu Nov 28 2002 - 11:34:05 CET


I agree with you in that the protocol is ugly for your purpose, however
it shouldn't be that difficult to devise abstractions that implement a
more appropriate protocol for the implementation at hand. The good news
is as always that you can do it.

As simple idea for a protocol that might fit your bill is having two
mappings: one mapping atoms such as "regular", "symmetric", ... to
integers and another one that maps the integers back to the atoms. Then
together with Space.choose (see my recent posting on this group) you can
devise abstractions that only use atoms as opposed to numbers.

Restricting the basic functionailty to integers is still okay, I am dead
sure that the spaces do not need any additional complexity by default...
Trust me on that ;-)

Cheers
Christian

"Gabor Szokoli" <gabor.szokoli@vanderbilt.edu> wrote in message
news:<03fa01c2925f$a054b6d0$5a593b81@szocske>...
> 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/.

-
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/.



This archive was generated by hypermail 2b29.