|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.)
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.
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.
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?
Fitts law movements currently do not enforce any kind of visual guidance contraints. They probably should.
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.
No currently pressing issues, mostly because nobody's really pushing on this one.
No currently pressing issues, again mostly because nobody's really pushing on this one.
Should there be more tracing options? If so, what else should be traced? What else could be done to make debugging easier?
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?
|People Facilities Research Projects Miscellany Search | Home|
Last modified 2002.05.30