Question from a novice

Fri Apr 21 10:34:43 EDT 2000

--------------D8B23C2FB67184CDE547B6DB
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Dear Nathan!
I'm also a bit of a novice, so I feel sympathetic with you.

ad the IF-THEN-Syntax of ACT-R production rules:
The reason for this is, I think, the ambition of the ACT community to
model the steps of human cognition on the atomic level, i.e. as detailed
as possible. A production which contains an IF-THEN-ELSE structure
implies that the following cognitive steps have already been made: the
criterion for a certain course of action has been identified (IF), and a
possible/ plausible/ whatever alternative action as well (ELSE).
Basically, this is an entire strategy, compressed in a single production
rule.
The reason to break down production rules to the simpler IF-THEN is that
this constraint enables the modeller to model the gradual formation of
strategies, the underlying learning processes and so on.

Although you write that to generate more production rules would be
"cumbersome" there are, I think some quite nice solutions to the
IF-THEN-ELSE problem.
 You can  implement such a stucture in a straightforward way by writing
three production rules, the first containing a retieval request for the
information:
(p search information
=goal>
isa goal
information nil
=infomation>
content something
==>
=goal>
information something)

and two productions implementing the then/else part, both checking the
"something"retrieved in the production before. The first contains in its
condition part that the information be your IF, however you specify it.
If "something" is this IF, the action occurs. The alternative one is
just checking for the information NOT being the special IF you want it
to be, via a negation check.
In plain english this would be something like:
(P altenative 1
IF the goal is (whatever), and there is information of a certain type,
THEN action)
(p altenative 2
IF the goal is whatever, and there is some information available, which
is not of this type, THEN different action)

By using the negation check you don't have to specvify altenatives, thus
having an equivalent to the if-then-else structure.
The formal syntax of this could be:

(p alternative1
=goal>
isa goal
information specified-by-you
==>action!)

(p alternative2
=goal>
isa goal
- information specified by you
==> different action!)

There may be more sophisticated ways to do that, especially the larning
and modification of such strategies, but unfortunatley I'm under a
little bit of time pressure at the moment and can't expand on the topic,
maybe some of the experts have some first hand modelling experience for
you.
I wish you all the best, and have fun with your modelling!
Stefani

> I've been evaluating a supervisory control task and translating user
> strategies into production rules (written in plain english).  As I was
> preparing the rules I noticed certain situations where I would normally
> use the conditional expression IF-THEN-ELSE. In my short relatively short
> time working with ACT-R, I've only seen a condition and action
> (IF-THEN).  I suspect there is a good reason why this is the case and so
> I was hoping someone could help me understand alternatives to
> IF-THEN-ELSE expressions in ACT-R.  Although one route is through
> generating more rules, this seemed to be a more cumbersome approach.
>
> Thanks!
>
> ________________________________________________________________
>
>

--------------D8B23C2FB67184CDE547B6DB
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML>
Dear Nathan!
 I'm also a bit of a novice, so I feel sympathetic with you.
ad the IF-THEN-Syntax of ACT-R production rules:
 The reason for this is, I think, the ambition of the ACT community
to model the steps of human cognition on the atomic level, i.e. as detailed
as possible. A production which contains an IF-THEN-ELSE structure implies
that the following cognitive steps have already been made: the criterion
for a certain course of action has been identified (IF), and a possible/
plausible/ whatever alternative action as well (ELSE). Basically, this
is an entire strategy, compressed in a single production rule.
 The reason to break down production rules to the simpler IF-THEN is
that this constraint enables the modeller to model the gradual formation
of strategies, the underlying learning processes and so on.
Although you write that to generate more production rules would be "cumbersom
e"
there are, I think some quite nice solutions to the IF-THEN-ELSE problem.
  You can  implement such a stucture in a straightforward
way by writing three production rules, the first containing a retieval
request for the information:
 (p search information
 =goal>
 isa goal
 information nil
 =infomation>
 content something
 ==>
 =goal>
 information something)
and two productions implementing the then/else part, both checking the
"something"retrieved in the production before. The first contains in its
condition part that the information be your IF, however you specify it.
If "something" is this IF, the action occurs. The alternative one is just
checking for the information NOT being the special IF you want it to be,
via a negation check.
 In plain english this would be something like:
 (P altenative 1
 IF the goal is (whatever), and there is information of a certain type,
 THEN action)
 (p altenative 2
 IF the goal is whatever, and there is some information available, which
is not of this type, THEN different action)
By using the negation check you don't have to specvify altenatives,
thus having an equivalent to the if-then-else structure.
 The formal syntax of this could be:
(p alternative1
 =goal>
 isa goal
 information specified-by-you
 ==>action!)
(p alternative2
 =goal>
 isa goal
 - information specified by you
 ==> different action!)
There may be more sophisticated ways to do that, especially the larning
and modification of such strategies, but unfortunatley I'm under a little
bit of time pressure at the moment and can't expand on the topic, maybe
some of the experts have some first hand modelling experience for you.
 I wish you all the best, and have fun with your modelling!
 Stefani
<BLOCKQUOTE TYPE=CITE>
<PRE>I've been evaluating a supervisory control task and translating user
strategies into production rules (written in plain english).  As I was
preparing the rules I noticed certain situations where I would normally
use the conditional expression IF-THEN-ELSE. In my short relatively short
time working with ACT-R, I've only seen a condition and action
(IF-THEN).  I suspect there is a good reason why this is the case and so
I was hoping someone could help me understand alternatives to
IF-THEN-ELSE expressions in ACT-R.  Although one route is through
generating more rules, this seemed to be a more cumbersome approach.

Thanks! 

________________________________________________________________

</PRE>
</BLOCKQUOTE>
</HTML>

--------------D8B23C2FB67184CDE547B6DB--