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.
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/?member_id=8660244&id_secret=108809214-a0d121
Powered by Listbox: http://www.listbox.com
