 |
|
| Computers Forum Index » Computer Artificial Intelligence - Shells » sub-goals... |
|
Page 1 of 1 |
|
| Author |
Message |
| Gene... |
Posted: Sun Jan 04, 2009 10:19 pm |
|
|
|
Guest
|
This group seems to be mostly announcements - not sure if this is the
place for discussion, but I'll try
I am new to this field, and am working on a diagnostic system. I'm
trying to use backward chaining. I haven't decided how to implement
this - perhaps prolog. I do have to interface to external applications
to collect data but the prologs I've looked at can interface to C, or
use sockets.
Anyhow, here is my question. I'll use the common "car won't start"
example application. Here are some highly simplified pseudo-code rules
(leaving out confidence factors, and other details).
1. IF engine-wont-turn-over THEN car-wont-start.
2. IF battery-dead THEN engine-wont-turn-over.
3. IF lights-wont-work THEN battery-dead
4. IF lights-on > 4 hours THEN battery-dead.
5. IF battery-age > 4 AND lights-on > 1 hour THEN battery-dead.
My initial goal is 'car-wont-start' and after asking the user if the
engine turns over, and then if the lights work, I find the cause is
"battery-dead.' This uses rules 1, 2, and 3. Depending on the
inference engine it might or might not use rules 4 and 5 (e.g. after
rule 3 we will have 100% confidence in battery-dead so rules 4 and 5
are really not needed). But thinking about it, rules 4 and 5 are
different from rule 3. Rule 3 indicates a method to determine if
battery-dead is true, whereas rules 4 and 5 indicate how to determine
why the battery is dead.
So let's say I do this:
1. IF engine-wont-turn-over THEN car-wont-start.
2. IF battery-dead THEN engine-wont-turn-over.
3. IF lights-wont-work THEN battery-dead
4. IF lights-on > 4 hours THEN battery-dead-reason.
5. IF battery-age > 4 AND lights-on > 1 hour THEN battery-dead-reason.
After we find the reason the car won't start is battery-dead, then we
start a new goal "battery-dead-reason" I might want the shell to
support the ability to specify this type of goal chaining. For
example, some way of specifying that if the fact "battery-dead" is
true, then to queue up a goal "battery-dead-reason" which will be
worked once the current "car-wont-start" goal work is done.
Is there a better way to think about this? |
|
|
| Back to top |
|
|
|
|
|
All times are GMT
The time now is Mon Nov 30, 2009 1:50 am
|
|