Parameter learning problem

[Niels Taatgen]

Suppose I have the following set of production-rules

(p retrieve-the-solution
  =goal>
    isa some-goal
    answer nil
  =fact>
    isa important-fact
    slot =answer
==>
  =goal>
    answer =answer)

(p calculate-the-solution
  =goal>
    isa some-goal
    answer nil
==>
  =fact>
    isa important-fact
    slot =answer
  =goal>
    answer =answer
  !push! =fact)

These tandems of rules are used often in many models: try to retrieve
the solution, if this doesn't work, push it as a subgoal and calculate
it.

Now suppose we now about 50% of all the possible facts, so
retrieve-the-solution
will succeed 50% of the time, and calculate-the-solution takes care of
the rest.
Suppose further that it takes about 5 seconds to calculate the solution.
So the
following values apply for a,b,q and r:

Retrieve-the-solution:
q=0.5, a=0.2, r=1, b=0 --> PG-C = 9.8

Calculate-the-solution:
q=1, a=5, r=1, b=0 --> PG-C = 15

So, in stead of trying to retrieve the fact, and if that fails calculate
it,
ACT-R will always calculate the fact. Since it will almost never try the
other rule, it will not discover that accumulation of facts has
increased the
value of q.

The problem is, that although the retrieve-rule might fail, you will
eventually reach the goal anyway, although at a slightly higher cost.

I see two possible ways solutions to this problem:

- Change the parameter learning scheme for q

If you do not count the failure to retrieve the fact as a failure, the
extra
cost of this failure will become part of b:

Retrieve-the-solution:
q=1, a=0.2, r=1, b=2.5 (since in 50% of the cases you still have to do a
calculate-the-solution) --> PG-C = 17.3

Calculate-the-solution:
q=1, a=5, r=1, b=0 --> PG-C = 15

- Change the semantics of production rules

The two production rules retrieve-the-solution and
calculate-the-solution very
often come in pairs. The striking thing is, that the dependencies needed
to learn these two rules are exactly the same, with only one difference:
in the retrieve-version the fact is stored in the contraints-slot, while
in
the calculate-version the fact is stored in the stack-slot.
So in stead of two rules, you might just want to have one rule, that
first
tries to retrieve the fact, and if this fails push it as a subgoal.
In most of my models this would save a lot of productions!

Since the second solution is rather radical, I only propose as food for
thought.
So I would in stead rather have a solution like the first one. Or, even
better,
a solution that doesn't need any change at all.

So, has anyone encountered similar problems with parameters learning,
and
has anyone come up with a solution yet?

Niels Taatgen.

-- 
-----------------------------------------------------------------------
Niels Taatgen
Technische Cognitiewetenschap / Cognitive Science and Engineering
Grote Kruisstraat 2/1
9712 TS Groningen, The Netherlands
Email: n.a.taatgen at bcn.rug.nl
WWW: http://tcw2.ppsw.rug.nl/~niels
-----------------------------------------------------------------------