Re: Assertion followed by retraction leads to error state...
Hans Chalupsky <[email protected]> Fri, 3 Oct 2008 14:41:14 -0700
| Newsgroups | gmane.comp.ai.powerloom |
|---|---|
| Message-ID | <[email protected]> |
Srini, comments in-line: >>>>> Srini Ram <[email protected]> writes: > Hi Hans > What you say below may work in a limited way (unassert followed by assert) but can still fail as the following shows > (defconcept person) > (defconcept rich (?x person)) > (defconcept poor (?x person)) > (assert (disjoint rich poor)) ;; person can be rich or poor but not both > (assert (rich jim)) > (retrieve all (rich ?x)) > #1: ?X=JIM ;; ok > (retrieve all (poor ?x)) > No solutions. ;; ok > (retrieve all (not (poor ?x))) > No solutions. ;; why dont i get jim, system can infer that jim is not poor > ;; since jim is rich, and rich/poor are disjoint. > ;; still, not important at this point The reason is that disjointness reasoning hasn't been all the way completed yet. Most of the infrastructure is there, but it hasn't been hooked into the inference engine yet. I'll see what it takes to get that working, I don't think all that much. The main reason I think why we've still been hedging on this were some performance implications. > (unassert (poor jim)) ;; whether it was asserted or not > (assert (poor jim)) ;; jim is now poor..Note because of disjunction it should not be necessary > ;; to state jim is no longer rich. Well, no. Even if our disjointness module were complete, this is not the behavior you would get. We distinguish between two kinds of truths, if you will (or epistemological status): assertions, where the user told us that something holds, and inferences, which follow from assertions and rules of logical inference. The fact that poor <=> not rich is an inference we (should) get from the disjointness assertion which then contradicts the explicit assertion that he is rich. But at that point PowerLoom doesn't know what to do, you've told it two (actually three) things that lead to a contradiction, which one is the correct one? It's not always the last one, since that could have simply been a mistake on your part. If you unassert poor, PowerLoom will not go out and try to infer all things that logically contradict it and unassert those also. Even if it tried that, there are in fact two things required to support that contradiction, the rich assertion and the disjointness assertion, retracting either one would solve the conflict. So which one should we choose? A standard dilemma in belief revision. Of course, one could special case this, but that would go a bit far, I think. What you should get (sometime during backward or forward inference), is a contradiction and an indicator what the reason is for the contradiction, so that you can then make up your mind what you really mean, i.e., whether Jim is really rich or poor or whether the two are maybe not disjoint, and you can then perform the appropriate maintenance. Hans > STELLA(28): (retrieve all (rich ?x)) > There is 1 solution: > #1: ?X=JIM ;; error, doesnt seem to have gone away > STELLA(29): (retrieve all (poor ?x)) > There is 1 solution: > #1: ?X=JIM > STELLA(30): (retrieve all (not (poor ?x))) > No solutions. > STELLA(31): (retrieve all (not (rich ?x))) > No solutions. > Maybe I need to add more rules to make this work, but then what is the point of having the disjoint statement? > Thanks > Srini > ----- Original Message ---- > From: Hans Chalupsky <[email protected]> > To: [email protected] > Cc: [email protected] > Sent: Friday, September 26, 2008 6:10:21 PM > Subject: Re: Assertion followed by retraction leads to error state... > Srini, > a proposition has at most one truth value per module or context. So, > when you asserted `(not (person jim))', it replaced the previously > asserted default truth value with FALSE (had the previous assertion > been a strict truth, it would have complained about a contradiction). > PowerLoom doesn't keep a history of prior truth values, so there is no > way to get back to the previous truth value with a retraction. > You might be able to get half of what you want by using `unassert' > instead of retract. With `unassert' you don't have to remember > whether you asserted a truth or falsity. So, you can simply call > `unassert' before each new assertion that might override a previous > truth value. Conceivably, we could invent a command that combines the > two into one. For example, > STELLA(3): (defconcept person) > |c|PERSON > STELLA(4): (unassert (person joe)) ;; ok, even if nothing was asserted yet > |P?|(PERSON JOE) > STELLA(5): (assert (not (person joe))) > |P|(NOT (PERSON JOE)) > STELLA(6): (unassert (person joe)) > |P?|(PERSON JOE) > STELLA(7): (assert (person joe)) > |P|(PERSON JOE) > STELLA(8): > Hans >>>>> Srini Ram <[email protected]> writes: >> I am experimenting with default truths and retraction... STELLA> (presume (person jim))à à ; assume that jim is a person >> |p|(PERSON JIM) STELLA> (ask (person jim)) >> TRUE STELLA> (assert (not (person jim)))à ;; we are told >> specifically that jim is not a >> personà à à à à à à à à à à à à >> |P|(NOT (PERSON JIM)) STELLA> (ask (person jim))à à à à à à à à à ; ok >> FALSE STELLA> (retract (not (person jim)))à ;; retract >> |P?|(PERSON JIM) STELLA> (ask (person jim)) >> UNKNOWNà à à à à à à à à à à à à à à à à à à à à à à à à à à à à à à à à à à à >> ;; wrong, we still have the presume >> ;; so by adding and retracting a fact we wound up >> ;; at a different state from where we started >> What I would like to happen is that new facts should be able to >> override old facts for cases where something can either be true or >> false...Since jim is either a person or not a person, I should not have >> to remember that I asserted that jim was not a person, and have to >> retract it before asserting the new knowledge that jim is in fact a >> person..From a maintenance perspective, this simplifies life a lot if >> we can assert new knowledge and have it simply replace prior (default) >> knowledge. > <html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:arial,helvetica,sans-serif;font-size:10pt"><div style="font-family: arial,helvetica,sans-serif; font-size: 10pt;">Hi Hans<br><br>What you say below may work in a limited way (unassert followed by assert) but can still fail as the following shows<br><br>(defconcept person)<br>(defconcept rich (?x person))<br>(defconcept poor (?x person))<br>(assert (disjoint rich poor)) ;; person can be rich or poor but not both<br><br><br>(assert (rich jim))<br><br>(retrieve all (rich ?x))<br>#1: ?X=JIM ;; ok<br>(retrieve all (poor ?x))<br>No solutions. ;; > ok<br><span style="color: rgb(127, 0, 63);">(retrieve all (not (poor ?x)))</span><br style="color: rgb(127, 0, 63);"><span style="color: rgb(127, 0, 63);">No solutions. ;; why dont i get jim, system can infer that jim is not poor</span><br style="color: rgb(127, 0, 63);"><span style="color: rgb(127, 0, 63);"> ;; since jim is rich, and rich/poor are disjoint.</span><br style="color: rgb(127, 0, 63);"><span style="color: rgb(127, 0, 63);"> ;; still, not important at this point</span><br><br>(unassert (poor jim)) ;; > whether it was asserted or not<br>(assert (poor jim)) ;; jim is now poor..Note because of disjunction it should not be necessary <br> ;; to state jim is no longer rich.<br><br>STELLA(28): (retrieve all (rich ?x))<br>There is 1 solution:<br> #1: ?X=JIM <span style="color: rgb(255, 0, 0);">;; error, doesnt seem to have gone away</span><br>STELLA(29): (retrieve all (poor ?x))<br>There > is 1 solution:<br> #1: ?X=JIM<br>STELLA(30): (retrieve all (not (poor ?x)))<br>No solutions.<br>STELLA(31): (retrieve all (not (rich ?x)))<br>No solutions.<br><br>Maybe I need to add more rules to make this work, but then what is the point of having the disjoint statement?<br><br>Thanks<br>Srini<br><br><br><div style="font-family: arial,helvetica,sans-serif; font-size: 13px;">----- Original Message ----<br>From: Hans Chalupsky <[email protected]><br>To: [email protected]<br>Cc: [email protected]<br>Sent: Friday, September 26, 2008 6:10:21 PM<br>Subject: Re: Assertion followed by retraction leads to error state...<br><br> > Srini,<br><br>a proposition has at most one truth value per module or context. So,<br>when you asserted `(not (person jim))', it replaced the previously<br>asserted default truth value with FALSE (had the previous assertion<br>been a strict truth, it would have complained about a contradiction).<br>PowerLoom doesn't keep a history of prior truth values, so there is no<br>way to get back to the previous truth value with a retraction.<br><br>You might be able to get half of what you want by using `unassert'<br>instead of retract. With `unassert' you don't have to remember<br>whether you asserted a truth or falsity. So, you can simply call<br>`unassert' before each new assertion that might override a previous<br>truth value. Conceivably, we could invent a command that combines the<br>two into one. For example,<br><br>STELLA(3): (defconcept person)<br>|c|PERSON<br>STELLA(4): (unassert (person joe)) ;; ok, even if nothing was > asserted yet<br>|P?|(PERSON JOE)<br>STELLA(5): (assert (not (person joe)))<br>|P|(NOT (PERSON JOE))<br>STELLA(6): (unassert (person joe))<br>|P?|(PERSON JOE)<br>STELLA(7): (assert (person joe))<br>|P|(PERSON JOE)<br>STELLA(8): <br><br>Hans<br><br>>>>>> Srini Ram <<a ymailto="mailto:[email protected]" href="mailto:[email protected]">[email protected]</a>> writes:<br><br>> I am experimenting with default truths and retraction...<br>STELLA> (presume (person jim))à à ; assume that jim is a person<br><br>> |p|(PERSON JIM)<br><br>STELLA> (ask (person jim))<br><br>> TRUE<br><br>STELLA> (assert (not (person jim)))à ;; we are told<br>> specifically that jim is not a<br>> personà à à à à à à à à à à à à <br><br>> |P|(NOT (PERSON JIM))<br><br>STELLA> (ask (person > jim))à à à à à à à à à ; ok<br>> FALSE<br><br>STELLA> (retract (not (person jim)))à ;; retract<br>> |P?|(PERSON JIM)<br><br>STELLA> (ask (person jim))<br><br>> UNKNOWNà à à à à à à à à à à à à à à à à à à à à à à à à à à à à à à à à à à à <br>> ;; wrong, we still have the presume<br>> ;; so by adding and retracting a fact we wound up<br><br>> ;; at a different state from where we started<br><br>> What I would like to happen is that new facts should be able to<br>> override old facts for cases where something can either be true or<br>> false...Since jim is either a person or not a person, I should not have<br>> to remember that I asserted that > jim was not a person, and have to<br>> retract it before asserting the new knowledge that jim is in fact a<br>> person..From a maintenance perspective, this simplifies life a lot if<br>> we can assert new knowledge and have it simply replace prior (default)<br>> knowledge.<br></div></div></div><br> > </body></html>_______________________________________________ > powerloom-forum mailing list > [email protected] > http://mailman.isi.edu/mailman/listinfo/powerloom-forum