Re: play(player, game)

>>>>> Octav Popescu <[email protected]> writes:

>> .....
>> Again, this is because of "asymmetric effort" for deriving what you
>> asked for vs. its negation.  When the query engine determined that
>> `(happy fred)' is unknown it stopped there, because that made the
>> conjunction fail.  It does not try to disprove any of the remaining
>> conjuncts to see whether it can prove the conjunction to be false
>> vs. just unknown.  Conceivably, we could be a bit more aggressive
>> there and at least look for shallow disproofs of other conjuncts
>> similar to what we do for atomic propositions.
>> 
>> If you explicitly ask for the negation, you get what you expect:
>> 
>> STELLA(38): (ask (not (and (happy fred) (happy joe))))
>> TRUE
>> 
>> We've considered to add a 3-valued-ask option (similar to Loom) that
>> would ask for the negation of the top-level goal automatically if the
>> positive was found to be unknown, for users who don't mind the extra
>> inference effort for the sake of more complete results.
>> ...
>> Hans

> The main thing that bothers me about the result above is that the evaluation 
> of predicates depends on the order of the predicates in the formula, and this 
> is not documented anywhere. I assume the predicates could also have 
> side-effects, and we should know whether they're going to be evaluated or 
> not. I assume that also means that if it has an (OR (P1 A) (P2 B)) and (P1 A) 
> is TRUE, it would not evaluate (P2 B).

Since this is logic, predicates should not have any side-effects and
evaluation order should be irrelevant.  For proving the truth of a
query, this is the case (modulo bugs), i.e., any which way you ask the
query you (should) get the same result.  In fact, PowerLoom moves
clauses around all the time in its query optimizer in order to try
first what it deems to be the cheapest.  This happens at the top level
as well as when chaining through rules (you have to explicitly disable
that with :dont-optimize? annotations to gain control over evaluation
order).  In the (OR (P1 A) (P2 B)) example above, it could be that (P2
B) is tried first if P1 has rules associated with it that might make
its evaluation more expensive.  And yes, if (P1 A) succeeds first, (P2
B) will not be asked about.

However, due to asymmetric effort for disproving a query, you once in
a while pick up a falsity in one evaluation order that doesn't come up
in another.  You should view those as a "bonus" :-), in older versions
of PowerLoom the only truth values you ever got were TRUE and UNKNOWN.
I just added a :three-valued? option to `ask' which will allow you to
ask for truth and falsity with the same effort which should eliminate
this asymmetry problem if you want to pay the additional inference
cost.

> Related to this I think it'd be very useful if PowerLoom comes with detailed 
> documentation about the inference processes it performs. Including how far it 
> goes and the exact semantics of the language constructs with respect to these 
> inference processes. One big problem I had with Loom was that when I was 
> using some language construct and I wasn't getting the effects I was 
> expecting, I had 4 different possible causes to investigate with no easy way 
> to figure out which one is the real one:

> 1. Misunderstanding of the semantics on my part.
> 2. Bug in my code.
> 3. Loom's incompleteness.
> 4. Bug in Loom.

> Good documentation should eliminate 1 and 3.

I agree that good documentation would eliminate many problems.  But
since we don't have any direct funding for PowerLoom development and
distribution, we can only do so much in our spare time.  We try, and
it hopefully is improving over time, albeit slowly :-)

Hans