RPM Issues
	chil home > projects > ACT-R/PM >

Describes some of the open issues in the workings of ACT-R/PM. If you are an RPM user, please feel free to comment on any or all of these issues. (Mike's email is at the bottom of the page.)

Scheduler/Master Process/Link to Cognition

• Reference Counts
  Base-level learning is dependent on reference counts, which are defined by a goal pop, a chunk merge, or a retrieval. It seems like chunks which represent percepts also ought to get a reference count, too, perhaps when they are attended, or maybe when they're referenced? Not sure what the best way to do this would be.

Vision Module

• Exogenously-driven attentional shifts
  People tend to shift attention to things that onset or move. This behavior may be insenstive to the current goal. At present, RPM does not exhibit this behavior, but there is a hook for some bottom-up effects in ACT-R 5.0. No current proposals.

• The :SCALE parameter
  The old Visual Interface supported three specialized scales, PHRASE, WORD, and COUNT. I don't like the COUNT scale because that seems to be building in subitizing. The other scales are OK, but perhaps too specific for text. There needs to be a lot more thinking done about how higher-order objects are synthesized out of visual features or lower-order objects, and there needs to be better code-level support for it.

• Psychological space
  Right now, RPM's representation of psychological visual/auditory space is severely limited. What's the best way to represent space, and how should that be integrated with the things that are already standing?

Motor Module

• Visual guidance
  Fitts law movements currently do not enforce any kind of visual guidance contraints. They probably should.

• Targeting "nothing"
  How big is an empty space? While some work has been done on this, particularly by the Mason crew, there is nothing definitive yet for the general case.

Audition Module

No currently pressing issues, mostly because nobody's really pushing on this one.

Speech Module

No currently pressing issues, again mostly because nobody's really pushing on this one.

Implementation

• Tracing
  Should there be more tracing options? If so, what else should be traced? What else could be done to make debugging easier?

• Parameters
  There are a lot of parameters, and they aren't named very consistently. Would it be better to generate a bunch of not-backward-compatible names to get the naming straight, or should the current system of crummy names be extended?

email Mike

	People   Facilities   Research   Projects   Miscellany   Search   |   Home

Last modified 2002.05.30