Nabble - PowerLoom

Re: Question about all-facts-of..

2008-08-27T10:54:31Z

Oops. Initially missed the second part of the question.

On Aug 27, 2008, at 8:57 AM, Srini Ram wrote:

>
>
> Also are
> Function: all-facts-of-instance ((self OBJECT) (includeunknownfacts?
> BOOLEAN) (elaborate? BOOLEAN)) : (LIST OF PROPOSITION) Return a list
> of all definite (TRUE or FALSE) propositions attached to self.
> N-Command: all-facts-of-n ((n INTEGER) &rest (instanceRefs NAME)) :
> (CONS OF PROPOSITION) available (as documented in the misc section).
> I get an error when trying to use them.

They work for me.

ALL-FACTS-OF-INSTANCE:

Note that this is a function, and so requires the actual objects to be
passed. You will not be able to invoke it from the standard PowerLoom
prompt. It needs to be called from code. (Of course, in Lisp, you
can call it directly, but you have to pass arguments of the proper
types:

* (all-facts-of-instance (pli:get-object "BILL" null null) cl:nil
cl:nil)
|l|(|P|(PERSON BILL) |P|(FRIEND BILL BOB))

Note that the return type is a Stella LIST object.

ALL-FACTS-OF-N:

This is a command and so is useable from the standard PowerLoom prompt
as well as being available as a Lisp form in the top-level REPL.

* (all-facts-of-n 0 bill)
(|P|(PERSON BILL) |P|(FRIEND BILL BOB))

* (all-facts-of-n 1 bill)
(|P|(PERSON BILL) |P|(FRIEND BILL BOB) |P|(PERSON BOB) |P|(FRIEND
BOB JOE))

* (all-facts-of-n 2 bill)
(|P|(PERSON BILL) |P|(FRIEND BILL BOB) |P|(PERSON BOB) |P|(FRIEND
BOB JOE)
|P|(PERSON JOE))

_______________________________________________
powerloom-forum mailing list
powerloom-forum@...
http://mailman.isi.edu/mailman/listinfo/powerloom-forum

Re: Question about all-facts-of..

2008-08-27T10:38:26Z

ALL-FACTS-OF only reports asserted (and forward-chained) information,
not cached information from running the query engine.

N-Command: all-facts-of ((instanceRef NAME)) : (CONS OF PROPOSITION)

Return a cons list of all definite (TRUE or FALSE) propositions that
reference the instance instanceRef. This includes propositions
asserted to be true by default, but it does not include propositions
that are found to be TRUE only by running the query engine. Facts
inferred to be TRUE by the forward chainer will be included. Hence,
the returned list of facts may be longer in a context where the
forward chainer has been run then in one where it has not (see run-
forward-rules).

On Aug 27, 2008, at 8:57 AM, Srini Ram wrote:

> Hi,
>
> If I have
>
> (defconcept person (?x))
> (defrelation alive (?x))
>
> (defconcept live-person (?x person)
> :<=> (alive ?x)
> )
> (defrelation spouse ((?x person) (?y person))
> :axioms (symmetric spouse))
>
> (defrelation married ((?x person) (?y person))
> :<=> (and (spouse ?x ?y) (live-person ?x) (live-person ?y) ))
>
> (assert (spouse jack jill))
> (assert (and (alive jack) (alive jill)))
>
> Now I do the following queries:
>
> STELLA> (all-facts-of jack)
> (|P|(SPOUSE JACK JILL) |P|(ALIVE JACK) |P|(PERSON JACK) |P?|(LIVE-
> PERSON JACK))
>
> STELLA> (retrieve all (married ?x ?y))
> There are 2 solutions:
> #1: ?X=JACK, ?Y=JILL
> #2: ?X=JILL, ?Y=JACK
>
> STELLA> (all-facts-of jack)
> (|P|(SPOUSE JACK JILL) |P|(ALIVE JACK) |P|(PERSON JACK) |P?|(LIVE-
> PERSON JACK)) ;; no (married jack jill)
>
> Should I not see married jack jill on the last query? I expect it to
> be cached as a fact after the query. How can I have access to such
> dynamic attributes of jack in all-facts-of. I tried :elaborate?
> TRUE as an argument of all-facts-of, to no avail.
>
> Also are
> Function: all-facts-of-instance ((self OBJECT) (includeunknownfacts?
> BOOLEAN) (elaborate? BOOLEAN)) : (LIST OF PROPOSITION) Return a list
> of all definite (TRUE or FALSE) propositions attached to self.
> N-Command: all-facts-of-n ((n INTEGER) &rest (instanceRefs NAME)) :
> (CONS OF PROPOSITION) available (as documented in the misc section).
> I get an error when trying to use them.
>
> Thanks
> Srini
>
> _______________________________________________
> powerloom-forum mailing list
> powerloom-forum@...
> http://mailman.isi.edu/mailman/listinfo/powerloom-forum

_______________________________________________
powerloom-forum mailing list
powerloom-forum@...
http://mailman.isi.edu/mailman/listinfo/powerloom-forum

Question about all-facts-of..

2008-08-27T08:57:55Z

Hi,

If I have

(defconcept person (?x))
(defrelation alive (?x))

(defconcept live-person (?x person)
:<=> (alive ?x)
)
(defrelation spouse ((?x person) (?y person))
:axioms (symmetric spouse))

(defrelation married ((?x person) (?y person))
:<=> (and (spouse ?x ?y) (live-person ?x) (live-person ?y) ))

(assert (spouse jack jill))
(assert (and (alive jack) (alive jill)))

Now I do the following queries:

STELLA> (all-facts-of jack)
(|P|(SPOUSE JACK JILL) |P|(ALIVE JACK) |P|(PERSON JACK) |P?|(LIVE-PERSON JACK))

STELLA> (retrieve all (married ?x ?y))
There are 2 solutions:
#1: ?X=JACK, ?Y=JILL
#2: ?X=JILL, ?Y=JACK

STELLA> (all-facts-of jack)
(|P|(SPOUSE JACK JILL) |P|(ALIVE JACK) |P|(PERSON JACK) |P?|(LIVE-PERSON JACK)) ;; no (married jack jill)

Should I not see married jack jill on the last query? I expect it to be cached as a fact after the query. How can I have access to such dynamic attributes of jack in all-facts-of. I tried :elaborate? TRUE as an argument of all-facts-of, to no avail.

Also are

Function: all-facts-of-instance ((self OBJECT) (includeunknownfacts? BOOLEAN) (elaborate? BOOLEAN)) : (LIST OF PROPOSITION): Return a list of all definite (TRUE or FALSE) propositions attached to self.

N-Command: all-facts-of-n ((n INTEGER) &rest (instanceRefs NAME)) : (CONS OF PROPOSITION)

available (as documented in the misc section). I get an error when trying to use them.

Thanks
Srini

_______________________________________________
powerloom-forum mailing list
powerloom-forum@...
http://mailman.isi.edu/mailman/listinfo/powerloom-forum

Re: Unexpected Powerloom truth maintenance behavior....

2008-08-22T17:17:00Z

Srini,

actually, the rules do match what you wrote, even though somewhat
counterintuitively:

(defrelation married ((?x live-person) (?y live-person)))

means the following:

(defrelation married (?x ?y))
(nth-domain married 0 live-person)
(nth-domain married 1 live-person)

In turn, the domain assertions mean that

(=> (married ?x ?y) (and (live-person ?x) (live-person ?y)))

BUT: this rule is not (yet) explicitly represented and currently only
enforced for top-level assertions (with some caveats - see an earlier
message). The reason is primarily efficiency, since we do not want to
unconditionally create all the additional type assertions for each
asserted relation, and we also don't want to do this via rules and
infer types via backward inference, since type rules often have high
fanout. So, for now we punted the ball on this in your corner and let
you explicitly assert such type inference rules if you deem them
necessary. And yes, you won't yet find this anywhere in the manual.

Now, this

(defrelation married ((?x live-person) (?y live-person))
Â :<=> (spouse ?x ?y))

currently means the following:

(defrelation married (?x ?y))
(nth-domain married 0 live-person)
(nth-domain married 1 live-person)
(forall (?x ?y) (<=> (married ?x ?y) (spouse ?x ?y)))

So, as you observed, the rule is built without the variable types
which explains the inferences and rules you saw. You can of course
fold in the type constraints explicitly, e.g.,

(defrelation married ((?x live-person) (?y live-person))
Â :<=> (and (live-person ?x)
(live-person ?y)
(spouse ?x ?y)))

or you can write the rule outside the relation definition in any which
way you want to enforce the type tests.

But, this behavior has been confusing to people (including myself) in
the past, and we have to think a bit more whether we should change
it or not. So, stay tuned.

Hans

--------------------------------------------------------------------------
Hans Chalupsky, PhD USC Information Sciences Institute
Project Leader, Loom KR&R Group 4676 Admiralty Way
<hans@...> Marina del Rey, CA 90292
(310) 448-8745
--------------------------------------------------------------------------

>>>>> Srini Ram <srini_ramaswamy_i@...> writes:

> I just tried to check the rules for my second version of married below and found:
> (print-rules married)

> (/PL-KERNEL-KB/FORALL (?x1 ?x2)
> Â Â (<= (SPOUSE ?x1 ?x2)
> Â Â Â Â Â Â (MARRIED ?x1 ?x2)))

> (/PL-KERNEL-KB/FORALL (?x1 ?x2)
> Â Â (<= (MARRIED ?x1 ?x2)
> Â Â Â Â Â Â (SPOUSE ?x1 ?x2)))

> This does not match what I wrote:

> (defrelation married ((?x live-person) (?y live-person))
> Â Â Â :<=> (and (spouse ?x ?y) ))

> For some reason, the rules are not converted to

> FORALL ((?x1 live-person) (?x2 live-person))
Â Â (<= (MARRIED ?x1 ?x2)
> Â Â Â Â Â (SPOUSE ?x1 ?x2)))

> but specified universally. This is why married continues to hold even
> if jack is no longer live, and why the explanations and traces show
> married follwign directly from an assertion?

> Srini

> --- On Fri, 8/22/08, Srini Ram <srini_ramaswamy_i@...> wrote:
> From: Srini Ram <srini_ramaswamy_i@...>
> Subject: Re: [PowerLoom Forum] Unexpected Powerloom truth maintenance behavior....
> To: powerloom-forum@...
> Date: Friday, August 22, 2008, 11:23 AM

> Hi Hans

> Can do...Will assert types explicitly.

> I am experiening the following issue:

> With following definitions:

> (defconcept person (?x))

> (defrelation alive (?x))

> (defconcept live-person (?x person)

> Â :<=> (alive ?x)

> Â )

> (defrelation spouse ((?x person) (?y person))

> Â :axioms (symmetric spouse))

> ;; (defrelation married ((?x person) (?y person))

> ;;Â Â Â :<=> (and (spouse ?x ?y) (live-person ?x) (live-person ?y) ))

> (assert (spouse jack jill))

> (assert (and (alive jack) (alive jill)))

> I get the following correct response;

STELLA> (retrieve all (married ?x ?y))

> There are 2 solutions:

> Â #1: ?X=JILL, ?Y=JACK

> Â #2: ?X=JACK, ?Y=JILL

STELLA> (retract (alive jack))

> |P?|(ALIVE JACK)

STELLA> (retrieve all (married ?x ?y))

> No solutions.

> But by changing the definition of married as follows:

> (defrelation married ((?x live-person) (?y live-person))

> Â Â Â :<=> (and (spouse ?x ?y) ))

> I get an erroneous answer

STELLA> (retrieve all (married ?x ?y))

> There are 2 solutions:

> Â #1: ?X=JACK, ?Y=JILL

> Â #2: ?X=JILL, ?Y=JACK

STELLA> (retract (alive jack))

> |P?|(ALIVE JACK)

STELLA> (retrieve all (married ?x ?y))

> There are 2 solutions:

> Â #1: ?X=JACK, ?Y=JILL

> Â #2: ?X=JILL, ?Y=JACK

STELLA> (retrieve all (married ?x ?y))

> There are 2 solutions:

> Â #1: ?X=JACK, ?Y=JILL

> Â #2: ?X=JILL, ?Y=JACK

> Just to check

STELLA> (ask (live-person jack))

> UNKNOWN

> Explanations not helpful:

STELLA> (set-feature justifications)

> |l|(:JUSTIFICATIONS :EMIT-THINKING-DOTS :JUST-IN-TIME-INFERENCE)

STELLA> (retrieve (married ?x ?y))

> There is 1 solution so far:

> Â #1: ?X=JACK, ?Y=JILL

STELLA> (why)

> |kv|(<|i|@PRIMITIVE-STRATEGY,|i|@EXPLANATION-INFO>)

> 1 (MARRIED JACK JILL)

> Â Â Â follows

> Nor does this:

STELLA> (set-feature trace-subgoals)

> |l|(:TRACE-SUBGOALS :JUSTIFICATIONS :EMIT-THINKING-DOTS :JUST-IN-TIME-INFERENCE)

STELLA> (retrieve (married ?x ?y))

> There is 1 solution so far:

> Â #1: ?X=JACK, ?Y=JILL

> PATTERN: [F,F]

> | GOAL: (MARRIED ?x ?y)

> | SUCC: ?X=JACK ?Y=JILL truth=T

> This is a bit disappointing since the ability of PL to classify
> dynamically and have rules being applicable based on that dynamic
> classification is very useful. In the above example, it does not seem
> that the dynamic classification is happening.

> I tried to force re-evaluation just in case the reevaluation of married needed a trigger:

STELLA> (process-definitions)

> COMMON-LISP:NIL

STELLA> (retrieve (married ?x ?y))

> There is 1 solution so far:

> Â #1: ?X=JACK, ?Y=JILL

> but that didnt work...

> Thanks

> Srini

> --- On Thu, 8/21/08, Hans Chalupsky <hans@...> wrote:
> From: Hans Chalupsky <hans@...>
> Subject: Re: [PowerLoom Forum] Unexpected Powerloom truth maintenance behavior....
> To: srini_ramaswamy_i@...
> Cc: "Thomas Russ" <tar@...>, powerloom-forum@...
> Date: Thursday, August 21, 2008, 4:09 PM

> Yes, we have to see how to improve this. Currently, the type
> assertions inferred from the domains of a relation are handled by a
> special mechanism if *type-check-policy* is
> :AUTOMATICALLY-FIX-TYPE-VIOLATIONS (the default). They are asserted
> in the top-level module and not the inference cache, and we can't
> blindly remove them, since they might have been asserted explicitly or
> be the result of other assertions as well. We only want to assert
> them if we have to,
> which is why they are handled somewhat differently
> from other inferred information.

> One way to work around this for now is to set *type-check-policy* to
> :REPORT-TYPE-VIOLATIONS and then assert all types explicitly, in which
> case it is your responsibility to assert and retract them, but at
> least you won't be surprised by PowerLoom doing things behind the
> scenes.

> Hans

>>>>> Thomas Russ <tar@...> writes:

>> On Aug 21, 2008, at 9:31 AM, Srini Ram wrote:

>>> (defmodule "TEST"
>>> :includes ("PL-USER"))
>>> (in-module "TEST")
>>>
>>> ;(clear-module "TEST")
>>> (reset-features)
>>>
>>> (defconcept person (?x))
>>> (defrelation spouse ((?x person) (?y person))
>>> :axioms (symmetric spouse))
>>>
>>> (assert (spouse jack jill)) ; expect (person jack) (person jill) to
>>> be also
> asserted because of domain of person
>>>
>>> (ask (person jack))
>>> TRUE ;; as expected
>>>
>>> (retract (spouse jack jill)) ;; expect (person jack) to
>>> also be retracted by truth maintenance system
>>>
>>> (ask (person jack))
>>> TRUE ;; unexpected
>>>
>>> Am I missing something.

>> No. PowerLoom is missing something.
>> This is a bug.

>> I'm not sure about how to fix it, though.

>> _______________________________________________
>> powerloom-forum mailing list
>> powerloom-forum@...
>> http://mailman.isi.edu/mailman/listinfo/powerloom-forum

_______________________________________________
powerloom-forum mailing list
powerloom-forum@...
http://mailman.isi.edu/mailman/listinfo/powerloom-forum

Re: Unexpected Powerloom truth maintenance behavior....

2008-08-22T11:53:05Z

I just tried to check the rules for my second version of married below and found:
(print-rules married)
(/PL-KERNEL-KB/FORALL (?x1 ?x2)
   (<= (SPOUSE ?x1 ?x2)
       (MARRIED ?x1 ?x2)))

(/PL-KERNEL-KB/FORALL (?x1 ?x2)
   (<= (MARRIED ?x1 ?x2)
       (SPOUSE ?x1 ?x2)))

This does not match what I wrote:
(defrelation married ((?x live-person) (?y live-person))
    :<=> (and (spouse ?x ?y) ))

For some reason, the rules are not converted to
FORALL ((?x1 live-person) (?x2 live-person))
   (<= (MARRIED ?x1 ?x2)
       (SPOUSE ?x1 ?x2)))

but specified universally. This is why married continues to hold even if jack is no longer live, and why the explanations and traces show married follwign directly from an assertion?

Srini

--- On Fri, 8/22/08, Srini Ram <srini_ramaswamy_i@...> wrote:

From: Srini Ram <srini_ramaswamy_i@...>
Subject: Re: [PowerLoom Forum] Unexpected Powerloom truth maintenance behavior....
To: powerloom-forum@...
Date: Friday, August 22, 2008, 11:23 AM
Hi Hans

Can do...Will assert types explicitly.

I am experiening the following issue:
With following definitions:

(defconcept person (?x))
(defrelation alive (?x))

(defconcept live-person (?x person)
:<=> (alive ?x)
)
(defrelation spouse ((?x person) (?y person))
:axioms (symmetric spouse))

;; (defrelation married ((?x person) (?y person))
;;    :<=> (and (spouse ?x ?y) (live-person ?x) (live-person ?y) ))

(assert (spouse jack jill))
(assert (and (alive jack) (alive jill)))

I get the following correct response;

STELLA> (retrieve all (married ?x ?y))
There are 2 solutions:
#1: ?X=JILL, ?Y=JACK
#2: ?X=JACK, ?Y=JILL
STELLA> (retract (alive jack))
|P?|(ALIVE JACK)
STELLA> (retrieve all (married ?x ?y))
No solutions.

But by changing the definition of married as follows:

(defrelation married ((?x live-person) (?y live-person))
    :<=> (and (spouse ?x ?y) ))

I get an erroneous answer

STELLA> (retrieve all (married ?x ?y))
There are 2 solutions:
#1: ?X=JACK, ?Y=JILL
#2: ?X=JILL, ?Y=JACK
STELLA> (retract (alive jack))
|P?|(ALIVE JACK)
STELLA> (retrieve all (married ?x ?y))
There are 2 solutions:
#1: ?X=JACK, ?Y=JILL
#2: ?X=JILL, ?Y=JACK
STELLA> (retrieve all (married ?x ?y))
There are 2 solutions:
#1: ?X=JACK, ?Y=JILL
#2: ?X=JILL, ?Y=JACK

Just to check

STELLA> (ask (live-person jack))
UNKNOWN

Explanations not helpful:

STELLA> (set-feature justifications)
|l|(:JUSTIFICATIONS :EMIT-THINKING-DOTS :JUST-IN-TIME-INFERENCE)
STELLA> (retrieve (married ?x ?y))
There is 1 solution so far:
#1: ?X=JACK, ?Y=JILL
STELLA> (why)
|kv|(<|i|@PRIMITIVE-STRATEGY,|i|@EXPLANATION-INFO>)
1 (MARRIED JACK JILL)
    follows

Nor does this:

STELLA> (set-feature trace-subgoals)
|l|(:TRACE-SUBGOALS :JUSTIFICATIONS :EMIT-THINKING-DOTS :JUST-IN-TIME-INFERENCE)
STELLA> (retrieve (married ?x ?y))
There is 1 solution so far:
#1: ?X=JACK, ?Y=JILL

PATTERN: [F,F]
| GOAL: (MARRIED ?x ?y)
| SUCC: ?X=JACK ?Y=JILL truth=T

This is a bit disappointing since the ability of PL to classify dynamically and have rules being applicable based on that dynamic classification is very useful. In the above example, it does not seem that the dynamic classification is happening.

I tried to force re-evaluation just in case the reevaluation of married needed a trigger:

STELLA> (process-definitions)
COMMON-LISP:NIL
STELLA> (retrieve (married ?x ?y))
There is 1 solution so far:
#1: ?X=JACK, ?Y=JILL

but that didnt work...

Thanks
Srini

--- On Thu, 8/21/08, Hans Chalupsky <hans@...> wrote:
From: Hans Chalupsky <hans@...>
Subject: Re: [PowerLoom Forum] Unexpected Powerloom truth maintenance behavior....
To: srini_ramaswamy_i@...
Cc: "Thomas Russ" <tar@...>, powerloom-forum@...
Date: Thursday, August 21, 2008, 4:09 PM
Yes, we have to see how to improve this.  Currently, the type
assertions inferred from the domains of a relation are handled by a
special mechanism if *type-check-policy* is
:AUTOMATICALLY-FIX-TYPE-VIOLATIONS (the default).  They are asserted
in the top-level module and not the inference cache, and we can't
blindly remove them, since they might have been asserted explicitly or
be the result of other assertions as well.  We only want to assert
them if we have to,

 which is why they are handled somewhat differently
from other inferred information.

One way to work around this for now is to set *type-check-policy* to
:REPORT-TYPE-VIOLATIONS and then assert all types explicitly, in which
case it is your responsibility to assert and retract them, but at
least you won't be surprised by PowerLoom doing things behind the
scenes.

Hans

>>>>> Thomas Russ <tar@...> writes:

> On Aug 21, 2008, at 9:31 AM, Srini Ram wrote:

>> (defmodule "TEST"
>> :includes ("PL-USER"))
>> (in-module "TEST")
>> 
>> ;(clear-module "TEST")
>> (reset-features)
>> 
>> (defconcept person (?x))
>> (defrelation spouse ((?x person) (?y person))
>> :axioms (symmetric spouse))
>> 
>> (assert (spouse jack jill))  ; expect (person jack) (person jill) to  
>> be
 also
 asserted because of  domain of  person
>> 
>> (ask (person jack))
>> TRUE                                      ;; as expected
>> 
>> (retract (spouse jack jill))          ;; expect (person jack) to  
>> also be retracted by truth maintenance system
>> 
>> (ask (person jack))
>> TRUE                                     ;; unexpected
>> 
>> Am I missing something.

> No.  PowerLoom is missing something.
> This is a bug.

> I'm not sure about how to fix it, though.

> _______________________________________________
> powerloom-forum mailing list
> powerloom-forum@...
> http://mailman.isi.edu/mailman/listinfo/powerloom-forum

_______________________________________________
powerloom-forum mailing list
powerloom-forum@...
http://mailman.isi.edu/mailman/listinfo/powerloom-forum

Re: Unexpected Powerloom truth maintenance behavior....

2008-08-22T11:23:06Z

Hi Hans

Can do...Will assert types explicitly.

I am experiening the following issue:
With following definitions:

(defconcept person (?x))
(defrelation alive (?x))

(defconcept live-person (?x person)
:<=> (alive ?x)
)
(defrelation spouse ((?x person) (?y person))
:axioms (symmetric spouse))

;; (defrelation married ((?x person) (?y person))
;; :<=> (and (spouse ?x ?y) (live-person ?x) (live-person ?y) ))

(assert (spouse jack jill))
(assert (and (alive jack) (alive jill)))

I get the following correct response;

STELLA> (retrieve all (married ?x ?y))
There are 2 solutions:
#1: ?X=JILL, ?Y=JACK
#2: ?X=JACK, ?Y=JILL
STELLA> (retract (alive jack))
|P?|(ALIVE JACK)
STELLA> (retrieve all (married ?x ?y))
No solutions.

But by changing the definition of married as follows:

(defrelation married ((?x live-person) (?y live-person))
:<=> (and (spouse ?x ?y) ))

I get an erroneous answer

STELLA> (retrieve all (married ?x ?y))
There are 2 solutions:
#1: ?X=JACK, ?Y=JILL
#2: ?X=JILL, ?Y=JACK
STELLA> (retract (alive jack))
|P?|(ALIVE JACK)
STELLA> (retrieve all (married ?x ?y))
There are 2 solutions:
#1: ?X=JACK, ?Y=JILL
#2: ?X=JILL, ?Y=JACK
STELLA> (retrieve all (married ?x ?y))
There are 2 solutions:
#1: ?X=JACK, ?Y=JILL
#2: ?X=JILL, ?Y=JACK

Just to check

STELLA> (ask (live-person jack))
UNKNOWN

Explanations not helpful:

STELLA> (set-feature justifications)
|l|(:JUSTIFICATIONS :EMIT-THINKING-DOTS :JUST-IN-TIME-INFERENCE)
STELLA> (retrieve (married ?x ?y))
There is 1 solution so far:
#1: ?X=JACK, ?Y=JILL
STELLA> (why)
|kv|(<|i|@PRIMITIVE-STRATEGY,|i|@EXPLANATION-INFO>)
1 (MARRIED JACK JILL)
follows

Nor does this:

STELLA> (set-feature trace-subgoals)
|l|(:TRACE-SUBGOALS :JUSTIFICATIONS :EMIT-THINKING-DOTS :JUST-IN-TIME-INFERENCE)
STELLA> (retrieve (married ?x ?y))
There is 1 solution so far:
#1: ?X=JACK, ?Y=JILL

PATTERN: [F,F]
| GOAL: (MARRIED ?x ?y)
| SUCC: ?X=JACK ?Y=JILL truth=T

This is a bit disappointing since the ability of PL to classify dynamically and have rules being applicable based on that dynamic classification is very useful. In the above example, it does not seem that the dynamic classification is happening.

I tried to force re-evaluation just in case the reevaluation of married needed a trigger:

STELLA> (process-definitions)
COMMON-LISP:NIL
STELLA> (retrieve (married ?x ?y))
There is 1 solution so far:
#1: ?X=JACK, ?Y=JILL

but that didnt work...

Thanks
Srini

--- On Thu, 8/21/08, Hans Chalupsky <hans@...> wrote:

From: Hans Chalupsky <hans@...>
Subject: Re: [PowerLoom Forum] Unexpected Powerloom truth maintenance behavior....
To: srini_ramaswamy_i@...
Cc: "Thomas Russ" <tar@...>, powerloom-forum@...
Date: Thursday, August 21, 2008, 4:09 PM

Yes, we have to see how to improve this.  Currently, the type
assertions inferred from the domains of a relation are handled by a
special mechanism if *type-check-policy* is
:AUTOMATICALLY-FIX-TYPE-VIOLATIONS (the default).  They are asserted
in the top-level module and not the inference cache, and we can't
blindly remove them, since they might have been asserted explicitly or
be the result of other assertions as well.  We only want to assert
them if we have to,
 which is why they are handled somewhat differently
from other inferred information.

One way to work around this for now is to set *type-check-policy* to
:REPORT-TYPE-VIOLATIONS and then assert all types explicitly, in which
case it is your responsibility to assert and retract them, but at
least you won't be surprised by PowerLoom doing things behind the
scenes.

Hans

>>>>> Thomas Russ <tar@...> writes:

> On Aug 21, 2008, at 9:31 AM, Srini Ram wrote:

>> (defmodule "TEST"
>> :includes ("PL-USER"))
>> (in-module "TEST")
>> 
>> ;(clear-module "TEST")
>> (reset-features)
>> 
>> (defconcept person (?x))
>> (defrelation spouse ((?x person) (?y person))
>> :axioms (symmetric spouse))
>> 
>> (assert (spouse jack jill))  ; expect (person jack) (person jill) to  
>> be also
 asserted because of  domain of  person
>> 
>> (ask (person jack))
>> TRUE                                      ;; as expected
>> 
>> (retract (spouse jack jill))          ;; expect (person jack) to  
>> also be retracted by truth maintenance system
>> 
>> (ask (person jack))
>> TRUE                                     ;; unexpected
>> 
>> Am I missing something.

> No.  PowerLoom is missing something.
> This is a bug.

> I'm not sure about how to fix it, though.

> _______________________________________________
> powerloom-forum mailing list
> powerloom-forum@...
> http://mailman.isi.edu/mailman/listinfo/powerloom-forum

_______________________________________________
powerloom-forum mailing list
powerloom-forum@...
http://mailman.isi.edu/mailman/listinfo/powerloom-forum

Re: Unexpected Powerloom truth maintenance behavior....

2008-08-22T11:00:14Z

Thanks Tom,

The :NONE issue was at the source of most of my problems....Its fine now.

I had tried with parens around variables, but it hadnt worked. I guess the :NONE was
the issue there.
(ask (forall (?x ?y) (=> (and (spouse ?x ?y) (alive ?x) (alive ?y)) (married ?x ?y))))
Evaluation aborted.

Same query seems to work now with the :NONE issue fixed..

As for why I didnt see the error, it was because I am using slime, and the error is actually seen in another buffer (the actual lisp process) which I was not monitoring.

Thanks
Srini

--- On Thu, 8/21/08, Thomas Russ <tar@...> wrote:

From: Thomas Russ <tar@...>
Subject: Re: [PowerLoom Forum] Unexpected Powerloom truth maintenance behavior....
To: srini_ramaswamy_i@...
Cc: powerloom-forum@...
Date: Thursday, August 21, 2008, 3:23 PM

On Aug 21, 2008, at 10:59 AM, Srini Ram wrote:

> Another issue I observed:
> (defmodule "TEST"
>   :includes ("PL-USER"))
> (in-module "TEST");;  repeat this if evaluating in STELLA
>
> (clear-module "TEST")
> (reset-features)
>
> (defconcept person (?x))
> (defrelation alive (?x))
> (defrelation spouse ((?x person) (?y person))
>   :axioms (symmetric spouse))
>
> (defrelation married ((?x person) (?y person))
>     :<=> (and
 (spouse ?x ?y) (alive ?x) (alive ?y)))
>
> STELLA> (ask (forall ?x ?y (=> (and (spouse ?x ?y) (alive ?x)  
> (alive ?y)) (married ?x ?y))))
> :NULL_VALUE
> STELLA> (ask (forall (?x person) (?y person) (=> (and (spouse ?x ?y)

> (alive ?x) (alive ?y)) (married ?x ?y))))
> :NULL_VALUE
>
> Shouldnt the above asks work? Is there any error in the asks?

The asks are syntactically mal-formed.  You need to put parentheses  
around the variable list, like so:

    (ask (forall (?x ?y) (=> (and (spouse ?x ?y) (alive ?x) (alive ? 
y)) (married ?x ?y))))

Then it works for me.  The query returns TRUE.

When I tried your original version, I got the following error message:

PARSING ERROR: Illegal ASK query: `((FORALL ?X ?Y
                                      (=>
                                       (AND (SPOUSE ?X ?Y) (ALIVE ?X)

                           (ALIVE ?Y))
                                       (MARRIED ?X ?Y))))'.

Did that not show up in your version?
Do you redirect *error-output* by any chance?

This also works similarly for the second query:

(ask (forall ((?x person) (?y person)) (=> (and (spouse ?x ?y) (alive ? 
x) (alive ?y)) (married ?x ?y))))

>
>
> I tried (setq *type-check-strategy* :NONE)

If you typed this at the top level in Lisp, then it would
explain the second error you reported.  This will set the
value of *type-check-strategy* to the LISP keyword :NONE,
and it needs to be set to the STELLA keyword :NONE instead.

To make sure you get Stella keywords, you have to take a
bit more care.  It is one area where the integration with
the Lisp READ-EVAL-PRINT loop is not complete.  That is because
we don't really want to muck around with the reader to change
the way
 symbols are read.  So you have to make sure you provide
the appropriate keyword value.

The easiest way to do that is to use the PLI:GET-KEYWORD function:

STELLA> (pli:get-keyword "NONE")
:NONE
STELLA> (cl:describe cl:*)
:NONE is an instance of class #<COMMON-LISP:STANDARD-CLASS KEYWORD>.
The following slots have :INSTANCE allocation:
  HOME-CONTEXT    :NULL_VALUE
  SYMBOL-NAME     "NONE"
  SYMBOL-ID       24
; No value
STELLA> (cl:describe :none)
:NONE is an external symbol in #<COMMON-LISP:PACKAGE
"KEYWORD">.
It is a constant; its value is :NONE.
; No value

So you would need to do

    (setq *type-check-strategy* (pli:get-keyword "NONE"))

in order to have things work properly.

_______________________________________________
powerloom-forum mailing list
powerloom-forum@...
http://mailman.isi.edu/mailman/listinfo/powerloom-forum

Re: Unexpected Powerloom truth maintenance behavior....

2008-08-21T16:09:53Z

Yes, we have to see how to improve this. Currently, the type
assertions inferred from the domains of a relation are handled by a
special mechanism if *type-check-policy* is
:AUTOMATICALLY-FIX-TYPE-VIOLATIONS (the default). They are asserted
in the top-level module and not the inference cache, and we can't
blindly remove them, since they might have been asserted explicitly or
be the result of other assertions as well. We only want to assert
them if we have to, which is why they are handled somewhat differently
from other inferred information.

One way to work around this for now is to set *type-check-policy* to
:REPORT-TYPE-VIOLATIONS and then assert all types explicitly, in which
case it is your responsibility to assert and retract them, but at
least you won't be surprised by PowerLoom doing things behind the
scenes.

Hans

>>>>> Thomas Russ <tar@...> writes:

> On Aug 21, 2008, at 9:31 AM, Srini Ram wrote:

>> (defmodule "TEST"
>> :includes ("PL-USER"))
>> (in-module "TEST")
>>
>> ;(clear-module "TEST")
>> (reset-features)
>>
>> (defconcept person (?x))
>> (defrelation spouse ((?x person) (?y person))
>> :axioms (symmetric spouse))
>>
>> (assert (spouse jack jill)) ; expect (person jack) (person jill) to
>> be also asserted because of domain of person
>>
>> (ask (person jack))
>> TRUE ;; as expected
>>
>> (retract (spouse jack jill)) ;; expect (person jack) to
>> also be retracted by truth maintenance system
>>
>> (ask (person jack))
>> TRUE ;; unexpected
>>
>> Am I missing something.

> No. PowerLoom is missing something.
> This is a bug.

> I'm not sure about how to fix it, though.

> _______________________________________________
> powerloom-forum mailing list
> powerloom-forum@...
> http://mailman.isi.edu/mailman/listinfo/powerloom-forum
_______________________________________________
powerloom-forum mailing list
powerloom-forum@...
http://mailman.isi.edu/mailman/listinfo/powerloom-forum

Re: Unexpected Powerloom truth maintenance behavior....

2008-08-21T15:44:06Z

Srini,

I think you just had the variable syntax wrong - if there are more
than one variable, they have to be in a list. Not sure why you didn't
get the following error message:

STELLA(34): (ask (forall ?x ?y (=> (and (spouse ?x ?y) (alive ?x) (alive ?y)) (married ?x ?y))))
PARSING ERROR: Illegal ASK query: `((FORALL ?X ?Y
(=> (AND (SPOUSE ?X ?Y) (ALIVE ?X) (ALIVE ?Y)) (MARRIED ?X ?Y))))'.
NULL
STELLA(35):

With that corrected (and inference tracing on just for debugging), you get
the desired result:

STELLA(32): (ask (forall (?x ?y) (=> (and (spouse ?x ?y) (alive ?x) (alive ?y)) (married ?x ?y))))
PATTERN: []
| GOAL: (FORALL (?x ?y)
(<= (MARRIED ?x ?y)
(AND (SPOUSE ?x ?y) (ALIVE ?x) (ALIVE ?y))))
| | GOAL: (FORALL (?x ?y)
(<= (MARRIED ?x ?y)
(AND (SPOUSE ?x ?y) (ALIVE ?x) (ALIVE ?y))))
| | | GOAL: (MARRIED ?x/anonymous-006 ?y/anonymous-007)
| | | | STRATEGY: :ANTECEDENTS
| | | | RULE: (FORALL (?x ?y)
(<= (MARRIED ?x ?y)
(AND (SPOUSE ?x ?y) (ALIVE ?x) (ALIVE ?y))))
| | | | | GOAL: (AND (SPOUSE ?x/anonymous-006 ?y/anonymous-007) (ALIVE ?x/anonymous-006) (ALIVE ?y/anonymous-007))
| | | | | | GOAL: (SPOUSE ?x/anonymous-006 ?y/anonymous-007)
| | | | | | SUCC: ?X=anonymous-006 ?Y=anonymous-007 truth=T
| | | | | | GOAL: (ALIVE ?x/anonymous-006)
| | | | | | SUCC: ?X=anonymous-006 ?Y=anonymous-007 truth=T
| | | | | | GOAL: (ALIVE ?y/anonymous-007)
| | | | | | SUCC: ?X=anonymous-006 ?Y=anonymous-007 truth=T
| | | | | SUCC: ?X=anonymous-006 ?Y=anonymous-007 truth=T
| | | | SUCC: ?X=anonymous-006 ?Y=anonymous-007 truth=T
| | | SUCC: ?Y=anonymous-007 ?X=anonymous-006 truth=T
| | SUCC: ?Y=anonymous-007 ?X=anonymous-006 truth=T
TRUE

Same for the other query:

STELLA(33): (ask (forall ((?x person) (?y person)) (=> (and (spouse ?x ?y) (alive ?x) (alive ?y)) (married ?x
?y))))
PATTERN: []
| GOAL: (FORALL (?x ?y)
(<= (MARRIED ?x ?y)
(AND (SPOUSE ?x ?y) (ALIVE ?x) (ALIVE ?y))))
| | GOAL: (FORALL (?x ?y)
(<= (MARRIED ?x ?y)
(AND (SPOUSE ?x ?y) (ALIVE ?x) (ALIVE ?y))))
| | | GOAL: (MARRIED ?x/anonymous-008 ?y/anonymous-009)
| | | | STRATEGY: :ANTECEDENTS
| | | | RULE: (FORALL (?x ?y)
(<= (MARRIED ?x ?y)
(AND (SPOUSE ?x ?y) (ALIVE ?x) (ALIVE ?y))))
| | | | | GOAL: (AND (SPOUSE ?x/anonymous-008 ?y/anonymous-009) (ALIVE ?x/anonymous-008) (ALIVE ?y/anonymous-009))
| | | | | | GOAL: (SPOUSE ?x/anonymous-008 ?y/anonymous-009)
| | | | | | SUCC: ?X=anonymous-008 ?Y=anonymous-009 truth=T
| | | | | | GOAL: (ALIVE ?x/anonymous-008)
| | | | | | SUCC: ?X=anonymous-008 ?Y=anonymous-009 truth=T
| | | | | | GOAL: (ALIVE ?y/anonymous-009)
| | | | | | SUCC: ?X=anonymous-008 ?Y=anonymous-009 truth=T
| | | | | SUCC: ?X=anonymous-008 ?Y=anonymous-009 truth=T
| | | | SUCC: ?X=anonymous-008 ?Y=anonymous-009 truth=T
| | | SUCC: ?Y=anonymous-009 ?X=anonymous-008 truth=T
| | SUCC: ?Y=anonymous-009 ?X=anonymous-008 truth=T
TRUE
STELLA(34):

Make sure you see the following rules, you had some funny non-breaking
space characters in the mail you sent which look like white space but
are treated as non-white space by PowerLoom:

STELLA(31): (print-rules married)
(FORALL (?x1 ?x2)
(<= (SPOUSE ?x1 ?x2)
(MARRIED ?x1 ?x2)))

(FORALL (?x ?y)
(=>> (MARRIED ?x ?y)
(AND (SPOUSE ?x ?y)
(ALIVE ?x)
(ALIVE ?y))))

(FORALL (?x ?y)
(<= (MARRIED ?x ?y)
(AND (SPOUSE ?x ?y)
(ALIVE ?x)
(ALIVE ?y))))

()
STELLA(32):

Hans

--------------------------------------------------------------------------
Hans Chalupsky, PhD USC Information Sciences Institute
Project Leader, Loom KR&R Group 4676 Admiralty Way
<hans@...> Marina del Rey, CA 90292
(310) 448-8745
--------------------------------------------------------------------------

>>>>> Srini Ram <srini_ramaswamy_i@...> writes:

> Another issue I observed:
> (defmodule "TEST"

> Â :includes ("PL-USER"))

> (in-module "TEST");;Â repeat this if evaluating in STELLA

> (clear-module "TEST")

> (reset-features)

> (defconcept person (?x))

> (defrelation alive (?x))

> (defrelation spouse ((?x person) (?y person))

> Â :axioms (symmetric spouse))

> (defrelation married ((?x person) (?y person))

> Â Â Â :<=> (and (spouse ?x ?y) (alive ?x) (alive ?y)))

STELLA> (ask (forall ?x ?y (=> (and (spouse ?x ?y) (alive ?x) (alive ?y)) (married ?x ?y))))

> :NULL_VALUE

STELLA> (ask (forall (?x person) (?y person) (=> (and (spouse ?x ?y) (alive ?x) (alive ?y)) (married ?x ?y))))

> :NULL_VALUE

> Shouldnt the above asks work? Is there any error in the asks?

> I tried (setq *type-check-strategy* :NONE)

> with no change...

> Thanks

> Srini

> --- On Thu, 8/21/08, Srini Ram <srini_ramaswamy_i@...> wrote:
> From: Srini Ram <srini_ramaswamy_i@...>
> Subject: Unexpected Powerloom truth maintenance behavior....
> To: powerloom-forum@...
> Date: Thursday, August 21, 2008, 9:31 AM

> (defmodule "TEST"

> Â :includes ("PL-USER"))

> (in-module "TEST")

> ;(clear-module "TEST")

> (reset-features)

> (defconcept person (?x))

> (defrelation spouse ((?x person) (?y person))

> Â :axioms (symmetric spouse))

> (assert (spouse jack jill))Â ; expect (person jack) (person jill) to be also asserted because ofÂ domain ofÂ person

> (ask (person jack))
> TRUEÂ Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
> ;; as expected

> (retract (spouse jack jill))Â Â Â Â Â Â Â Â Â ;; expect (person jack) to also be retracted by truth maintenance system

> (ask (person jack))

> TRUEÂ Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
> ;; unexpected

> Am I missing something.

> Thanks

> Srini

_______________________________________________
powerloom-forum mailing list
powerloom-forum@...
http://mailman.isi.edu/mailman/listinfo/powerloom-forum

Re: Powerloom demo test not working...

2008-08-21T15:25:49Z

See the note at the bottom of my other reply.

The problem is that the Lisp keyword :NONE was used instead of the
Stella keyword :NONE

Something else to make sure we add to the Lisp-specific documentation.

On Aug 21, 2008, at 3:13 PM, Thomas Russ wrote:

>
> On Aug 21, 2008, at 11:58 AM, Srini Ram wrote:
>
>> I am trying the following (from the test-suite.plm) in CMUCL
>
> This particular example works for me on CMUCL 19e:
>
> CMU Common Lisp 19e (19E), running on cowabunga.isi.edu
> With core: /opt/local/cmucl-19e/lib/cmucl/lib/lisp.core
> Dumped on: Thu, 2008-05-01 17:38:02-07:00 on macmini
> See <http://www.cons.org/cmucl/> for support information.
> Loaded subsystems:
> Python 1.1, target Intel x86
> CLOS based on Gerd's PCL 2004/04/14 03:32:47
>
>
>>
>>
>> ;;; PROPER HANDLING OF INEQUALITY RETRACTION
>>
>> (clear-module "TEST")
>>
>> (deffunction age (?p) :-> (?a integer))
>>
>> (assert (< (age bill) 12))
>> (assert (> (age bill) 10))
>>
>> ;;; SHOULD RETURN 11:
>> (retrieve ?x (= (age bill) ?x))
>>
>> Error in function HELP-BIND-VARIABLE-TO-VALUE?:
>> `:NONE' is not a valid case option
>> [Condition of type STELLA-EXCEPTION]
>>
>> Restarts:
>> 0: [ABORT] Return to SLIME's top level.
>> 1: [ABORT] Return to Top-Level.
>>
>> Backtrace:
>> 0: (HELP-BIND-VARIABLE-TO-VALUE? #<#1=unavailable-arg> #<#1#>)
>> 1: (ARGUMENTS-UNIFY-WITH-ARGUMENTS? #<#1=unavailable-arg> #<#1#>)
>> 2: (TRY-SCAN-PROPOSITIONS-PROOF #<unavailable-arg>)
>> ....
>> Evaluation aborted...
>
> I wonder if somehow your lisp version of PowerLoom didn't initialize
> properly when loading. There should be a single instance of the
> Stella keyword :NONE that is used.
>
> All of the following symbols are in the Stella package.
> The object used in the function where it is failing is stored in
> the variable
> kwd-query-none
> If this ends up not being a proper Stella keyword object, then
> there is some problem with the loading and initialization. All of
> that should happen automatically when PowerLoom loads.
>
> What is the value of kwd-query-none ?
>
> Also the value of
> *type-check-strategy*
> should also be a valid keyword, although since this gets set
> during processing, it will likely not be :none, but instead be :lookup
>
> If you load things into a fresh lisp, do you still have these
> problems?
>
>
>
>
>
> _______________________________________________
> powerloom-forum mailing list
> powerloom-forum@...
> http://mailman.isi.edu/mailman/listinfo/powerloom-forum

_______________________________________________
powerloom-forum mailing list
powerloom-forum@...
http://mailman.isi.edu/mailman/listinfo/powerloom-forum

Re: Unexpected Powerloom truth maintenance behavior....

2008-08-21T15:24:19Z

On Aug 21, 2008, at 9:31 AM, Srini Ram wrote:

> (defmodule "TEST"
> :includes ("PL-USER"))
> (in-module "TEST")
>
> ;(clear-module "TEST")
> (reset-features)
>
> (defconcept person (?x))
> (defrelation spouse ((?x person) (?y person))
> :axioms (symmetric spouse))
>
> (assert (spouse jack jill)) ; expect (person jack) (person jill) to
> be also asserted because of domain of person
>
> (ask (person jack))
> TRUE ;; as expected
>
> (retract (spouse jack jill)) ;; expect (person jack) to
> also be retracted by truth maintenance system
>
> (ask (person jack))
> TRUE ;; unexpected
>
> Am I missing something.

No. PowerLoom is missing something.
This is a bug.

I'm not sure about how to fix it, though.

_______________________________________________
powerloom-forum mailing list
powerloom-forum@...
http://mailman.isi.edu/mailman/listinfo/powerloom-forum

Re: Unexpected Powerloom truth maintenance behavior....

2008-08-21T15:23:35Z

On Aug 21, 2008, at 10:59 AM, Srini Ram wrote:

> Another issue I observed:
> (defmodule "TEST"
> :includes ("PL-USER"))
> (in-module "TEST");; repeat this if evaluating in STELLA
>
> (clear-module "TEST")
> (reset-features)
>
> (defconcept person (?x))
> (defrelation alive (?x))
> (defrelation spouse ((?x person) (?y person))
> :axioms (symmetric spouse))
>
> (defrelation married ((?x person) (?y person))
> :<=> (and (spouse ?x ?y) (alive ?x) (alive ?y)))
>
> STELLA> (ask (forall ?x ?y (=> (and (spouse ?x ?y) (alive ?x)
> (alive ?y)) (married ?x ?y))))
> :NULL_VALUE
> STELLA> (ask (forall (?x person) (?y person) (=> (and (spouse ?x ?y)
> (alive ?x) (alive ?y)) (married ?x ?y))))
> :NULL_VALUE
>
> Shouldnt the above asks work? Is there any error in the asks?

The asks are syntactically mal-formed. You need to put parentheses
around the variable list, like so:

(ask (forall (?x ?y) (=> (and (spouse ?x ?y) (alive ?x) (alive ?
y)) (married ?x ?y))))

Then it works for me. The query returns TRUE.

When I tried your original version, I got the following error message:

PARSING ERROR: Illegal ASK query: `((FORALL ?X ?Y
(=>
(AND (SPOUSE ?X ?Y) (ALIVE ?X)
(ALIVE ?Y))
(MARRIED ?X ?Y))))'.

Did that not show up in your version?
Do you redirect *error-output* by any chance?

This also works similarly for the second query:

(ask (forall ((?x person) (?y person)) (=> (and (spouse ?x ?y) (alive ?
x) (alive ?y)) (married ?x ?y))))

>
>
> I tried (setq *type-check-strategy* :NONE)

If you typed this at the top level in Lisp, then it would
explain the second error you reported. This will set the
value of *type-check-strategy* to the LISP keyword :NONE,
and it needs to be set to the STELLA keyword :NONE instead.

To make sure you get Stella keywords, you have to take a
bit more care. It is one area where the integration with
the Lisp READ-EVAL-PRINT loop is not complete. That is because
we don't really want to muck around with the reader to change
the way symbols are read. So you have to make sure you provide
the appropriate keyword value.

The easiest way to do that is to use the PLI:GET-KEYWORD function:

STELLA> (pli:get-keyword "NONE")
:NONE
STELLA> (cl:describe cl:*)
:NONE is an instance of class #<COMMON-LISP:STANDARD-CLASS KEYWORD>.
The following slots have :INSTANCE allocation:
HOME-CONTEXT :NULL_VALUE
SYMBOL-NAME "NONE"
SYMBOL-ID 24
; No value
STELLA> (cl:describe :none)
:NONE is an external symbol in #<COMMON-LISP:PACKAGE "KEYWORD">.
It is a constant; its value is :NONE.
; No value

So you would need to do

(setq *type-check-strategy* (pli:get-keyword "NONE"))

in order to have things work properly.

_______________________________________________
powerloom-forum mailing list
powerloom-forum@...
http://mailman.isi.edu/mailman/listinfo/powerloom-forum

Re: Powerloom demo test not working...

2008-08-21T15:13:03Z

On Aug 21, 2008, at 11:58 AM, Srini Ram wrote:

> I am trying the following (from the test-suite.plm) in CMUCL

This particular example works for me on CMUCL 19e:

CMU Common Lisp 19e (19E), running on cowabunga.isi.edu
With core: /opt/local/cmucl-19e/lib/cmucl/lib/lisp.core
Dumped on: Thu, 2008-05-01 17:38:02-07:00 on macmini
See <http://www.cons.org/cmucl/> for support information.
Loaded subsystems:
Python 1.1, target Intel x86
CLOS based on Gerd's PCL 2004/04/14 03:32:47

>
>
> ;;; PROPER HANDLING OF INEQUALITY RETRACTION
>
> (clear-module "TEST")
>
> (deffunction age (?p) :-> (?a integer))
>
> (assert (< (age bill) 12))
> (assert (> (age bill) 10))
>
> ;;; SHOULD RETURN 11:
> (retrieve ?x (= (age bill) ?x))
>
> Error in function HELP-BIND-VARIABLE-TO-VALUE?:
> `:NONE' is not a valid case option
> [Condition of type STELLA-EXCEPTION]
>
> Restarts:
> 0: [ABORT] Return to SLIME's top level.
> 1: [ABORT] Return to Top-Level.
>
> Backtrace:
> 0: (HELP-BIND-VARIABLE-TO-VALUE? #<#1=unavailable-arg> #<#1#>)
> 1: (ARGUMENTS-UNIFY-WITH-ARGUMENTS? #<#1=unavailable-arg> #<#1#>)
> 2: (TRY-SCAN-PROPOSITIONS-PROOF #<unavailable-arg>)
> ....
> Evaluation aborted...

I wonder if somehow your lisp version of PowerLoom didn't initialize
properly when loading. There should be a single instance of the
Stella keyword :NONE that is used.

All of the following symbols are in the Stella package.
The object used in the function where it is failing is stored in
the variable
kwd-query-none
If this ends up not being a proper Stella keyword object, then
there is some problem with the loading and initialization. All of
that should happen automatically when PowerLoom loads.

What is the value of kwd-query-none ?

Also the value of
*type-check-strategy*
should also be a valid keyword, although since this gets set
during processing, it will likely not be :none, but instead be :lookup

If you load things into a fresh lisp, do you still have these problems?

_______________________________________________
powerloom-forum mailing list
powerloom-forum@...
http://mailman.isi.edu/mailman/listinfo/powerloom-forum

Powerloom demo test not working...

2008-08-21T11:58:19Z

I am trying the following (from the test-suite.plm) in CMUCL

;;; PROPER HANDLING OF INEQUALITY RETRACTION

(clear-module "TEST")

(deffunction age (?p) :-> (?a integer))

(assert (< (age bill) 12))
(assert (> (age bill) 10))

;;; SHOULD RETURN 11:
(retrieve ?x (= (age bill) ?x))

Error in function HELP-BIND-VARIABLE-TO-VALUE?:
`:NONE' is not a valid case option
[Condition of type STELLA-EXCEPTION]

Restarts:
0: [ABORT] Return to SLIME's top level.
1: [ABORT] Return to Top-Level.

Backtrace:
0: (HELP-BIND-VARIABLE-TO-VALUE? #<#1=unavailable-arg> #<#1#>)
1: (ARGUMENTS-UNIFY-WITH-ARGUMENTS? #<#1=unavailable-arg> #<#1#>)
2: (TRY-SCAN-PROPOSITIONS-PROOF #<unavailable-arg>)
....
Evaluation aborted...

Thanks
Srini

_______________________________________________
powerloom-forum mailing list
powerloom-forum@...
http://mailman.isi.edu/mailman/listinfo/powerloom-forum

Re: Unexpected Powerloom truth maintenance behavior....

2008-08-21T10:59:39Z

Another issue I observed:
(defmodule "TEST"
:includes ("PL-USER"))
(in-module "TEST");; repeat this if evaluating in STELLA

(clear-module "TEST")
(reset-features)

(defconcept person (?x))
(defrelation alive (?x))
(defrelation spouse ((?x person) (?y person))
:axioms (symmetric spouse))

(defrelation married ((?x person) (?y person))
:<=> (and (spouse ?x ?y) (alive ?x) (alive ?y)))

STELLA> (ask (forall ?x ?y (=> (and (spouse ?x ?y) (alive ?x) (alive ?y)) (married ?x ?y))))
:NULL_VALUE
STELLA> (ask (forall (?x person) (?y person) (=> (and (spouse ?x ?y) (alive ?x) (alive ?y)) (married ?x ?y))))
:NULL_VALUE

Shouldnt the above asks work? Is there any error in the asks?

I tried (setq *type-check-strategy* :NONE)

with no change...

Thanks
Srini

--- On Thu, 8/21/08, Srini Ram <srini_ramaswamy_i@...> wrote:

From: Srini Ram <srini_ramaswamy_i@...>
Subject: Unexpected Powerloom truth maintenance behavior....
To: powerloom-forum@...
Date: Thursday, August 21, 2008, 9:31 AM

(defmodule "TEST"
:includes ("PL-USER"))
(in-module "TEST")

;(clear-module "TEST")
(reset-features)

(defconcept person (?x))
(defrelation spouse ((?x person) (?y person))
:axioms (symmetric spouse))

(assert (spouse jack jill)) ; expect (person jack) (person jill) to be also asserted because of domain of person

(ask (person jack))
TRUE                                      ;; as expected

(retract (spouse jack jill))          ;; expect (person jack) to also be retracted by truth maintenance system

(ask (person jack))
TRUE                                     ;; unexpected

Am I missing something.

Thanks
Srini

_______________________________________________
powerloom-forum mailing list
powerloom-forum@...
http://mailman.isi.edu/mailman/listinfo/powerloom-forum

Unexpected Powerloom truth maintenance behavior....

2008-08-21T09:31:21Z

(defmodule "TEST"
:includes ("PL-USER"))
(in-module "TEST")

;(clear-module "TEST")
(reset-features)

(defconcept person (?x))
(defrelation spouse ((?x person) (?y person))
:axioms (symmetric spouse))

(assert (spouse jack jill)) ; expect (person jack) (person jill) to be also asserted because of domain of person

(ask (person jack))
TRUE                                      ;; as expected

(retract (spouse jack jill))          ;; expect (person jack) to also be retracted by truth maintenance system

(ask (person jack))
TRUE                                     ;; unexpected

Am I missing something.

Thanks
Srini

_______________________________________________
powerloom-forum mailing list
powerloom-forum@...
http://mailman.isi.edu/mailman/listinfo/powerloom-forum

Re: Tried to bind |V|?x to NULL value.

2008-08-05T09:59:04Z

On Tue, Aug 5, 2008 at 12:03 AM, Hans Chalupsky <hans@...> wrote:
> What Tom said in his previous reply still applies, but your example
> did uncover a bug where PowerLoom picked up an incorrect description
> duplicate which led to the incorrect behavior you saw. This should be
> fixed with the next PowerLoom snapshot which should build
> automatically overnight. I ran your example again with the fixed
> version and it now answers everything correctly (the retrieve still
> doesn't give answers for the reasons Tom explained, but the asks now
> do the right thing).
>

That's great, you fixed the bug so quickly! I've just downloaded the
new snapshot and confirmed it works as described.

Regards,
_______________________________________________
powerloom-forum mailing list
powerloom-forum@...
http://mailman.isi.edu/mailman/listinfo/powerloom-forum

Re: Tried to bind |V|?x to NULL value.

2008-08-04T15:03:34Z

What Tom said in his previous reply still applies, but your example
did uncover a bug where PowerLoom picked up an incorrect description
duplicate which led to the incorrect behavior you saw. This should be
fixed with the next PowerLoom snapshot which should build
automatically overnight. I ran your example again with the fixed
version and it now answers everything correctly (the retrieve still
doesn't give answers for the reasons Tom explained, but the asks now
do the right thing).

Hans

STELLA(3): (defobject alice)
|i|ALICE
STELLA(4): (defobject bob)
|i|BOB
STELLA(5): (defrelation friend (?x ?y))
|r|FRIEND
STELLA(6): (ask (friend alice bob))
UNKNOWN
STELLA(7): (assert (forall (?x ?y) (friend ?x ?y)))
|P|(FORALL (?x ?y)
(<= (FRIEND ?x ?y)
TRUE))
STELLA(8): (ask (friend alice bob))
TRUE
STELLA(9): (retrieve (friend ?x ?y))
WARNING: Tried to bind |V|?x to NULL value. Potentially a PowerLoom bug
No solutions.
STELLA(10): (ask (friend alice bob))
TRUE
STELLA(11): (ask (forall (?x ?y) (friend ?x ?y)))
TRUE
STELLA(12): (all-facts-of alice)
()
STELLA(13): (all-facts-of friend)
(|P|(RELATION FRIEND) |P|(NTH-DOMAIN FRIEND 0 THING) |P|(NTH-DOMAIN FRIEND 1 THING)
|P?|(DUPLICATE-FREE FRIEND) |P|(FORALL (?x ?y)
(<= (FRIEND ?x ?y)
TRUE)))
;; this is now true, since it is applied by the rule above:
STELLA(14): (ask (forall ?x (friend ?x ?x)))
TRUE
STELLA(15):

>>>>> Thomas Russ <tar@...> writes:

> On Aug 2, 2008, at 1:26 PM, Martin Baldan wrote:

>> Hello!
>>
>> I'm a newbie trying to get a hang of this nice powerloom tool, but
>> I've run into a problem. During some simple tests, the bug mentioned
>> in the subject appeared, and I don't know what to make of it. Here's a
>> transcript of my session, which will explain it better than my own
>> words:

> OK. The main thing that is going on is that PowerLoom doesn't really
> like to do extremely open-ended reasoning, and the rule that you have
> formulated is very open ended. It says, essentially, that everything
> in the universe is the friend of everything else. That would give a
> really large result, and PowerLoom doesn't like to attempt to reason
> if things are that open ended.

> ------------
>>
>> PL-USER |= (powerloom-information)
>>
>> |L|"PowerLoom 3.2.0

> I would encourage you to use the current PowerLoom snapshot. It does
> include a number of bug fixes and is generally just as stable as the
> official "stable" release.

> This is the problem. The rule that you have is just too open-ended.
> It has the meaning that I noted above, and so everything should
> satisfy it. But PowerLoom won't try to reason with it, because it
> would be too inefficient, especially if it appeared somewhere as just
> one step of some logical chain of reasoning.

> As a general principle, you should never write a FORALL form without
> an implication (=> or <=) inside of it.

> So, a slightly better formulation might be to introduce additional
> concepts like person:

> (defconcept person)

> and then write a rule that applies only to people:

> (assert (forall (?x ?y) (=> (and (person ?x) (person ?y))
> (friend ?x ?y))))

>> PL-USER |= (ask (friend alice bob))
>>
>> UNKNOWN

> You would then need to tell PowerLoom that ALICE and BOB are people:

> (assert (and (person alice) (person bob)))

>>
>> PL-USER |= (retrieve (friend ?x ?y))
>>
>> WARNING: Tried to bind |V|?x to NULL value. Potentially a
>> PowerLoom bug
>> No solutions.

> The problem here is that PowerLoom doesn't have any good way to
> enumerate values of ?X, since the friend relation doesn't have any
> range or domain constraints. That means everything has to be
> considered as being friends, including the FRIEND relation itself,
> along with all sorts of PowerLoom internal defined things.

> This last transformation, though, is a bit odd. It looks like this
> may, in fact, be a bug in PowerLoom, since this transformation is not
> equivalent to the actual base rule.

> But since the base rule really isn't something you should be writing,
> we might take our time in tracking this down.

>>
>> PL-USER |= (ask (forall ?x (friend ?x ?x)))
>>
>> TRUE
>>
>> PL-USER |=
>>
>> ---------------------
>>
>> I hope someone can help me to work around this. Thanks in advance.
>> _______________________________________________
>> powerloom-forum mailing list
>> powerloom-forum@...
>> http://mailman.isi.edu/mailman/listinfo/powerloom-forum

> _______________________________________________
> powerloom-forum mailing list
> powerloom-forum@...
> http://mailman.isi.edu/mailman/listinfo/powerloom-forum

_______________________________________________
powerloom-forum mailing list
powerloom-forum@...
http://mailman.isi.edu/mailman/listinfo/powerloom-forum