Brad Paulsen wrote:
I've been following this thread pretty much since the beginning. I hope
I didn't miss anything subtle. You'll let me know if I have, I'm sure. ;=)
It appears the need for temporal dependencies or different levels of
reasoning has been conflated with the terms "forward-chaining" (FWC) and
"backward-chaining" (BWC), which are typically used to describe
different rule base evaluation algorithms used by expert systems.
The terms “forward-chaining” and “backward-chaining” when used to refer
to reasoning strategies have absolutely nothing to do with temporal
dependencies or levels of reasoning. These two terms refer simply, and
only, to the algorithms used to evaluate “if/then” rules in a rule base
(RB). In the FWC algorithm, the “if” part is evaluated and, if TRUE,
the “then” part is added to the FWC engine's output. In the BWC
algorithm, the “then” part is evaluated and, if TRUE, the “if” part is
added to the BWC engine's output. It is rare, but some systems use both
FWC and BWC.
That's it. Period. No other denotations or connotations apply.
Whooaa there. Something not right here.
Backward chaining is about starting with a goal statement that you would
like to prove, but at the beginning it is just a hypothesis. In BWC you
go about proving the statement by trying to find facts that might
support it. You would not start from the statement and then add
knowledge to your knowledgebase that is consistent with it.
So for example, if your goal is to prove that Socrates is mortal, then
your above desciption of BWC would cause the following to occur
1) Does any rule allow us to conclude that x is/is not mortal?
2) Answer: yes, the following rules allow us to do that:
"If x is a plant, then x is mortal"
"If x is a rock, then x is not mortal"
"If x is a robot, then x is not mortal"
"If x lives in a post-singularity era, then x is not mortal"
"If x is a slug, then x is mortal"
"If x is a japanese beetle, then x is mortal"
"If x is a side of beef, then x is mortal"
"If x is a screwdriver, then x is not mortal"
"If x is a god, then x is not mortal"
"If x is a living creature, then x is mortal"
"If x is a goat, then x is mortal"
"If x is a parrot in a Dead Parrot Sketch, then x is mortal"
3) Ask the knowledge base if Socrates is a plant, if Socrates is a rock,
etc etc ..... working through the above list.
3) [According to your version of BWC, if I understand you aright] Okay,
if we cannot find any facts in the KB that say that Socrates is known to
be one of these things, then add the first of these to the KB:
"Socrates is a plant"
[This is the bit that I question: we don't do the opposite of forward
chaining at this step].
4) Now repeat to find all rules that allow us to conclude that x is a
plant". For this set of " ... then x is a plant" rules, go back and
repeat the loop from step 2 onwards. Then if this does not work, ....
Well, you can imagine the rest of the story: keep iterating until you
can prove or disprove that Socrates is mortal.
I cannot seem to reconcile this with your statement above that backward
chaining simply involves the opposite of forward chaining, namely adding
antecedents to the KB and working backwards.
To help remove any mystery that may still surround these concepts, here
is an FWC algorithm in pseudo-code (WARNING: I'm glossing over quite a
few details here – I'll be happy to answer questions on list or off):
0. set loop index to 0
1. got next rule?
no: goto 5
2. is rule FIRED?
yes: goto 1
3. is key equal to rule's antecedent?
yes: add consequent to output, mark rule as FIRED,
output is new key, goto 0
4. goto 1
5. more input data?
yes: input data is new key, goto 0
6. done.
To turn this into a BWC algorithm, we need only modify Step #3 to read
as follows:
3. is key equal to rule's consequent?
yes: add antecedent to output, mark rule as FIRED,
output is new key, goto 0
If you need to represent temporal dependencies in FWC/BWC systems, you
have to express them using rules. For example, if washer-a MUST be
placed on bolt-b before nut-c can be screwed on, the rule base might
look something like this:
1. if installed(washer-x) then install(nut-z)
2. if installed(bolt-y) then install(washer-x)
3. if notInstalled(bolt-y) then install(bolt-y)
In this case, rule #1 won't get fired until rule #2 fires (nut-z can't
get installed until washer-x has been installed). Rule #2 won't get
fired until rule #3 has fired (washer-x can't get installed until bolt-y
has been installed). NUT-Z! (Sorry, couldn't help it.)
To kick things off, we pass in “bolt-y” as the initial key. This
triggers rule #3, which will trigger rule #2, which will trigger rule
#1. These temporal dependencies result in the following assembly
sequence: install bolt-y, then install washer-x, and, finally, install
nut-z.
A similar thing can be done to implement rule hierarchies.
1. if levelIs(0) and installed(washer-x) then install(nut-z)
2. if levelIs(0) and installed(nut-z) goLevel(1)
3. if levelIs(1) and notInstalled(gadget-xx) then install(gadget-xx)
4. if levelIs(0) and installed(bolt-y) then install(washer-x)
5. if levelIs(0) and notInstalled(bolt-y) then install(bolt-y)
Here rule #2 won't fire until rule #1 has fired. Rule #1 won't fire
unless rule #4 has fired. Rule #4 won't fire until rule #5 has fired.
And, finally, Rule #3 won't fire until Rule #2 has fired. So, level 0
could represent the reasoning required before level 1 rules (rule #3
here) will be of any use. (That's not the case here, of course, just
stretching my humble example as far as I can.)
Note, again, that the temporal and level references in the rules are NOT
used by the BWC. They probably will be used by the part of the program
that does something with the BWC's output (the install(), goLevel(),
etc. functions). And, again, the results should be completely unaffected
by the order in which the RB rules are evaluated or fired.
I hope this helps.
Cheers,
Brad
Richard Loosemore wrote:
Mike Tintner wrote:
A tangential comment here. Looking at this and other related threads
I can't help thinking: jeez, here are you guys still endlessly
arguing about the simplest of syllogisms, seemingly unable to
progress beyond them. (Don't you ever have that feeling?) My
impression is that the fault lies with logic itself - as soon as you
start to apply logic to the real world, even only tangentially with
talk of "forward" and "backward" or "temporal" considerations, you
fall into a quagmire of ambiguity, and no one is really sure what
they are talking about. Even the simplest if p then q logical
proposition is actually infinitely ambiguous. No? (Is there a
Godel's Theorem of logic?)
Well, now you have me in a cleft stick, methinks.
I *hate* logic as a way to understand cognition, because I think it is
a derivative process within a high-functional AGI system, not a
foundation process that sits underneath everything else.
But, on the other hand, I do understand how it works, and it seems a
shame for someone to trample on the concept of forward and backward
chaining when these are really quite clear and simple processes (at
least conceptually).
You are right that logic is as clear as mud outside the pristine
conceptual palace within which it was conceived, but if you're gonna
hang out inside the palace it is a bit of a shame to question its
elegance...
Richard Loosemore
-------------------------------------------
agi
Archives: https://www.listbox.com/member/archive/303/=now
RSS Feed: https://www.listbox.com/member/archive/rss/303/
Modify Your Subscription: https://www.listbox.com/member/?&;
Powered by Listbox: http://www.listbox.com
-------------------------------------------
agi
Archives: https://www.listbox.com/member/archive/303/=now
RSS Feed: https://www.listbox.com/member/archive/rss/303/
Modify Your Subscription:
https://www.listbox.com/member/?&;
Powered by Listbox: http://www.listbox.com
-------------------------------------------
agi
Archives: https://www.listbox.com/member/archive/303/=now
RSS Feed: https://www.listbox.com/member/archive/rss/303/
Modify Your Subscription:
https://www.listbox.com/member/?member_id=8660244&id_secret=108809214-a0d121
Powered by Listbox: http://www.listbox.com
