When I teach straight Prolog, I often start with problems like Zebra. The approach I take is to construct a list of terms such as [neighbor(Nationality, Color, Pet, ...) ...] Then I apply constraints to members of that list. It's a fairly straightforward program. For example, if the list of neighbors is called Neighbors, the clue that says the sculptor breeds snails would become something like the following.
member(Person, Neighbors),profession(Person, sculptor),pet(Person, snails)
where
profession(_Person, Profesion) :- member(Profession, [sculptor, doctor, ...])
It works for me as a way to introduce the power of both unification and built-in search.
My next step is to write a similar solution in Oz to see what it looks like.
This approach seems to me to be a much more intutive representation than the one that maps properties to house numbers, and it doesn't require translating constraints into integer constraints. One could do this in FD if FD were generalized to deal with sets of atoms and sequences of atoms instead of being limited to integers. (Is that on the list of enhancements?)
I'm taken by your remark that Prolog is the COBOL of logic programming languages. Are you saying that logic programming in Oz is that much better than logic programming in Prolog or that FD in better than logic programming? Much of the recent discussion was a defense of Oz as a logic programming language, one that was not just a super FD system.
-- Russ
On 10/7/05, Raphael Collet <[EMAIL PROTECTED]> wrote:
Russ Abbott wrote:
> Because much of the computation is encapsulated within a SearchAll, I
> found it difficult to debug. { Ozcar.breakpoint} doesn't seem to be
> triggered. I've been reduced to running very small subsections of the
> code in isolation or including a lot of output statements. Are there
> better ways?
Ozcar does not work with computation spaces:
http://www.mozart-oz.org/documentation/ozcar/node9.html#chapter.limitations
I don't know any better way in your situation :-( It is easier if you
use FD constraints, since you can run propagators in the toplevel space,
and observe how they prune variable domains. Distributors cannot be run
at the toplevel (for the reasons I explained in former emails).
> In any event, I've written a logic program version of the Zebra puzzle:
> http://www.mozart-oz.org/documentation/fdt/node23.html#section.elimination.zebra
> <http://www.mozart-oz.org/documentation/fdt/node23.html#section.elimination.zebra >.
> I followed the FD strategy as closely as I could, which was quite
> closely. It's a pretty straightforward translation--although it runs on
> a bit.
>
> The strategy is to fill in the house numbers for one of the groups of
> properties. (I used Colors, but it doesn't matter.) It then runs all
> the constraints. Finally, it fills in any values that had not been
> filled in by the constraints.
I had a closer look at your program. That's very close to the FD one,
indeed. The Colors trick is because the _expression_ Nb.green > Nb.white
blocks until both values are known.
> As you will see if you look at it, I couldn't figure out how to write a
> decent Adjacent. So the current version is just brute force. When I
> tried to use X+1 and X-1 etc., I couldn't get it to work. I still don't
> know why, so I've given up for now.
Here is an Adjacent predicate that generates all possibilies for X and Y
in the range 1..N, and then makes a choice with it.
%% X and Y are adjacent integers between 1 and N
proc {Adjacent N X Y}
Nums = {List.number 1 N-1 1} % the smallest one
Alts = {Append
{Map Nums fun {$ I} proc {$} X=I Y=I+1 end end}
{Map Nums fun {$ I} proc {$} Y=I X=I+1 end end}}
in
{ChoiceList Alts}
end
%% makes a choice with a non-empty list of procedures
proc {ChoiceList Ps}
case Ps
of [P] then {P}
[] P|Pr then choice {P} [] {ChoiceList Pr} end
end
end
I also forced myself to solve this problem in a "pure" logic style. The
difficulty to grasp performance issues really bothered me more than what
I expected. Reasoning with the FD solution is much simpler IMHO...
Prolog now definitively looks like the COBOL of logic languages to me.
Cheers,
raph
_________________________________________________________________________________
mozart-users mailing list [email protected]
http://www.mozart-oz.org/mailman/listinfo/mozart-users
--
_____________________________________________
Professor, Computer Science
California State University, Los Angeles
o Check out my blog at http://russabbott.blogspot.com/
_________________________________________________________________________________ mozart-users mailing list [email protected] http://www.mozart-oz.org/mailman/listinfo/mozart-users
