Parameter learning problem

[Christian Schunn]

The ubiquitous nature of the retrieve/compute pairing does make more
plausible the incorporation of it into the architecture as a special
case. I especially favor Niels' suggestion that the production
compilation mechanism automatically created both retrieval and
computation productions automatically.

 Let me propose a further variant. Since we have strong reason to
suspect that people can use the familiarility level of the problem
statement to decide whether to retrieve or calculate before trying
either (see Reder & Ritter, 1992 and Schunn et al, 1997), we might think
that the activation level of the goal statement could be used in
conflict resolution:

  IF Activation(goal) > Threshold THEN retrieve, else compute

The relative probabilities and costs for retrieval and computation could
enter into determining the threshold.

Alternatively, we could make the q for the retrieve production be a
simple (logistic?) function of the activation level of the goal. This
would keep the existing conflict resolution scheme basically intact.

The main idea underlying both of these schemes is that the past
retrieval and computations have created multiple copies of this goal
chunk, and thus it will come to have a higher base-level activation.
This, of course, requires that we don't modify the goal chunk when we
retrieve or compute the answer, but instead create a new copy with the
answer imbedded. Although this is not common practice, there have been
previous suggestions that this is the correct thing to do.

-Chris