pre.P contains a few predicates to get started with the project.
Boat capacity of 2 and 3 M's and 3 C's is the canonical M & C's problem.
Here is sample.in file with some queries and its corresponding sample.out.
The output file for an input file is obtained by executing: xsb < sample.in > sample.out
Q: Is the state safe when there are more missionaries than cannibals on one bank, and NO missionaries, but some cannibals on another?
A: yes, no one gets eaten in such a state.
Q: For some queries I get the same answer more than once, do I need to fix this?
A: This is ok. You don't need to worry about repeated answers. One possible reason why you get repeated answers is that your rules provide two ways to prove that a state is safe.
The problem instance with 4 Ms/Cs and boat cap. of 2 has no solution.
Q: in the sample output for bdfs, i noticed that the output displays from 0 to 2 depth and NOT just depth 2 plans. Why? won't this slow down computation? for example, if i run depth 2 with ids and it doesn't get the the goal i want, i'll increase to depth 3. However, at depth 3, it'll check the depth 0 to 2 as well, isn't this redundant? shouldn't bdfs just give the plans that are at the MaxDepth since with ids we've already checked ALL the depths before that?
A: bdfs represents a search algorithm by itself and is supposed to behave that way. When used in ids the result is a not very efficient algorithm and there are possibly many ways to improve it. I'm glad to see some of you have noticed this and are coming up with improvements. For the project though bdfs should find paths of any length up to the maxDepth since we specified it as a separate search relation.
this is the correct syntax of terms atBank() that you should use.
Another condition for a cross action to be possible is that the boat has to be on the side where the crossing originates, i.e.
possible(cross(west, 1, 0), state(atBank(2,3), boat(east))).
should succeed, whereas
possible(cross(west, 1, 0), state(atBank(2,3), boat(west))).
should fail.
Q: When I load my program, XSB displays the message: "specializing partially instantiated calls to function name". is this a problem?
A: Some times XSB optimizes some of the rules in a program. Such a message is a report that it is doing one such optimization. It is not an error or a problem with your program.
Q: I'm using genint to generate numbers. When a condition is not satisfied I generate another number. But genint always returns the same number! How should I proceed?
A: When you define a relation, the body of the rules say when the relation is true and Prolog takes care of the rest. For example, if you want to use genint to get numbers between 1 and 100 that satisfy some condition c(N), your rule would look like:
p(N):- genint(1,100,N), c(N).
Note the body of the rule doesn't say anything about the case when N doesn't satisfy c(N). The rule just says that N is a number between 1 and 100 that satisfies c(N). It is Prolog's job to find such numbers.