Unexpected Powerloom truth maintenance behavior....

View: New views
10 Messages — Rating Filter:   Alert me  

Unexpected Powerloom truth maintenance behavior....

by srini_ottawa :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

(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

Parent Message unknown Re: Unexpected Powerloom truth maintenance behavior....

by srini_ottawa :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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: Unexpected Powerloom truth maintenance behavior....

by Thomas Russ :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message


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

by Thomas Russ :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message


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

by Hans Chalupsky :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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: Unexpected Powerloom truth maintenance behavior....

by Hans Chalupsky :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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

by srini_ottawa :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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

by srini_ottawa :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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

Parent Message unknown Re: Unexpected Powerloom truth maintenance behavior....

by srini_ottawa :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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

by Hans Chalupsky :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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