From Wolfgang.Schoppek at uni-bayreuth.de Tue Oct 7 07:02:39 2003 From: Wolfgang.Schoppek at uni-bayreuth.de (Wolfgang Schoppek) Date: Tue, 07 Oct 2003 13:02:39 +0200 Subject: [ACT-R-users] stopping pm Message-ID: <3F829D4F.8000004@uni-bayreuth.de> What's the best way of stopping PM in open ended trials? (in order to run the between-trial LISP-code, which I don't want to be called from within a production rule!) I've been looking in the ACT-R/PM documentation and didn't find anything like "pm-stop". -- Wolfgang ----------------------------------------------------------------- Dr. Wolfgang Schoppek Universitaet Bayreuth Tel.: +49 921 554140 http://www.uni-bayreuth.de/departments/psychologie/wolfgang.html ----------------------------------------------------------------- From db30 at andrew.cmu.edu Tue Oct 7 10:13:34 2003 From: db30 at andrew.cmu.edu (db30 at andrew.cmu.edu) Date: Tue, 07 Oct 2003 10:13:34 -0400 Subject: [ACT-R-users] stopping pm In-Reply-To: <3F829D4F.8000004@uni-bayreuth.de> References: <3F829D4F.8000004@uni-bayreuth.de> Message-ID: <1912920.1065521614@whatever.psy.cmu.edu> --On Tuesday, October 07, 2003 1:02 PM +0200 Wolfgang Schoppek wrote: > What's the best way of stopping PM in open ended trials? (in order to run > the between-trial LISP-code, which I don't want to be called from within > a production rule!) I've been looking in the ACT-R/PM documentation and > didn't find anything like "pm-stop". -- Wolfgang I don't know the details of the experiment, but why do you need to "stop" the model? If you're using PM, then I assume that there's probably a response that the model makes which signals the end of the trial and you could just put the code that executes into the "handler" of that response. If you put the code into the device-handle-click, device-handle-keypress, or device-speak-string method it would just happen when it needed to and the model could be allowed to run the whole task continuously. If that isn't the case, please let me know more details and I'll offer some other suggestions. Dan From Wolfgang.Schoppek at uni-bayreuth.de Tue Oct 7 10:43:29 2003 From: Wolfgang.Schoppek at uni-bayreuth.de (Wolfgang Schoppek) Date: Tue, 07 Oct 2003 16:43:29 +0200 Subject: [ACT-R-users] stopping pm In-Reply-To: <1912920.1065521614@whatever.psy.cmu.edu> References: <3F829D4F.8000004@uni-bayreuth.de> <1912920.1065521614@whatever.psy.cmu.edu> Message-ID: <3F82D111.7010806@uni-bayreuth.de> Hi Dan, it's just a matter of program clarity. I would like to keep the code that controls the flow of the experiment as separate from ACT-R as possible. With your solutions (sort of which I've used in the past), ACT-R and experiment-control-code call each other mutually. I'd like to have a solution where calling experiment-control-code from ACT-R is reduced to a minimum. This could be easily done by a function like (pm-stop) called from the production that gives the answer. With such a solution, the function that runs a complete test block with open ended trials would look very clear: (defun recognize (ili) (setf *stimulus* ili) (pm-run) ; until it is stopped from the rhs of some production (do-after-trial-stuff) ) (defun do-test (stimuluslist &optional (fun #'recognize)) (dolist (ele stimuluslist) (funcall fun ele)) ) Thank you anyway, -- Wolfgang ----------------------------------------------------------------- Dr. Wolfgang Schoppek Universitaet Bayreuth Tel.: +49 921 554140 http://www.uni-bayreuth.de/departments/psychologie/wolfgang.html ----------------------------------------------------------------- From byrne at rice.edu Tue Oct 7 13:38:02 2003 From: byrne at rice.edu (Mike Byrne) Date: Tue, 7 Oct 2003 12:38:02 -0500 Subject: [ACT-R-users] stopping pm In-Reply-To: <3F82D111.7010806@uni-bayreuth.de> Message-ID: On 2003.10.07, Wolfgang Schoppek said: > Hi Dan, it's just a matter of program clarity. I would like to > keep the code that controls the flow of the experiment as > separate from ACT-R as possible. With your solutions (sort of > which I've used in the past), ACT-R and experiment-control-code > call each other mutually. I'd like to have a solution where > calling experiment-control-code from ACT-R is reduced to a > minimum. This could be easily done by a function like (pm-stop) > called from the production that gives the answer. With such a > solution, the function that runs a complete test block with open > ended trials would look very clear: > > (defun recognize (ili) > (setf *stimulus* ili) > (pm-run) ; until it is stopped from the rhs of some production > (do-after-trial-stuff) > ) > > (defun do-test (stimuluslist &optional (fun #'recognize)) > (dolist (ele stimuluslist) > (funcall fun ele)) > ) If there is no chunk in the goal buffer, ACT-R will halt. Thus, if you do a !pop!, ACT-R will stop once there's nothing in the event queue. This may not be the "Christian & Dan approved" way of stopping ACT-R, but it's effective. Other production systems (e.g. OPS5), do have an explicit RHS HALT operator. Perhaps we ought to consider such a thing for ACT-R 6.0. -Mike =========================================================== Mike Byrne, Ph.D. byrne at acm.org Assistant Professor, Psychology Department Rice University, MS-25 http://chil.rice.edu/byrne/ 6100 Main Street +1 713-348-3770 voice Houston, TX 77005-1892 +1 713-348-5221 fax From cl at andrew.cmu.edu Tue Oct 7 14:57:08 2003 From: cl at andrew.cmu.edu (Christian Lebiere) Date: Tue, 07 Oct 2003 14:57:08 -0400 Subject: [ACT-R-users] stopping pm In-Reply-To: References: Message-ID: <1444762684.1065538628@zip.act.cs.cmu.edu> > If there is no chunk in the goal buffer, ACT-R will halt. Thus, if you > do a !pop!, ACT-R will stop once there's nothing in the event queue. > This may not be the "Christian & Dan approved" way of stopping ACT-R, but > it's effective. It is not as much a matter of a seal of approval as looking at theoretical coherence and forward compatibility. Since the goal is just another buffer now there is really no reason to stop the system when the goal is empty as when any other buffer is empty, which happens all the time. More practically, the trick worked because without a goal you were assured that no production could fire. But now, productions don't have to match the goal so even without a goal a production could fire that sets a new goal. So while the trick might still work now, who knows for how long? > Other production systems (e.g. OPS5), do have an explicit RHS HALT > operator. Perhaps we ought to consider such a thing for ACT-R 6.0. There is a RHS !stop! operator. It should still work for (run) but not (pm-run), but we could try to generalize it to that effect. Of course, that assumes that we want to hang on to the !bang! syntax, or else find a suitable alternative. Christian From db30 at andrew.cmu.edu Tue Oct 7 18:04:47 2003 From: db30 at andrew.cmu.edu (db30 at andrew.cmu.edu) Date: Tue, 07 Oct 2003 18:04:47 -0400 Subject: [ACT-R-users] stopping pm In-Reply-To: <3F82D111.7010806@uni-bayreuth.de> References: <3F829D4F.8000004@uni-bayreuth.de> <1912920.1065521614@whatever.psy.cmu.edu> <3F82D111.7010806@uni-bayreuth.de> Message-ID: <30186095.1065549887@whatever.psy.cmu.edu> --On Tuesday, October 07, 2003 4:43 PM +0200 Wolfgang Schoppek wrote: > Hi Dan, > it's just a matter of program clarity. I would like to keep the code that > controls the flow of the experiment as separate from ACT-R as possible. > With your solutions (sort of which I've used in the past), ACT-R and > experiment-control-code call each other mutually. I'd like to have a > solution where calling experiment-control-code from ACT-R is reduced to a > minimum. This could be easily done by a function like (pm-stop) called > from the production that gives the answer. With such a solution, the > function that runs a complete test block with open ended trials would > look very clear: > > (defun recognize (ili) > (setf *stimulus* ili) > (pm-run) ; until it is stopped from the rhs of some production > (do-after-trial-stuff) > ) > > (defun do-test (stimuluslist &optional (fun #'recognize)) > (dolist (ele stimuluslist) > (funcall fun ele)) > ) > I agree that experiment code and the model should be kept as separate as possible. It seems thought that we differ on our views of the system. Here's my opinion on the matter. First and foremost, I'll say that I consider the ACT-R implementation as a very powerful and very general tool that can be used in many different ways for many different purposes, and as such there really isn't a right and wrong. So please don't feel that I'm trying to say there's anything wrong with how you're trying to use it, and your question just seemed like a good way to start a discussion of these types of issues that seem to come up occasionally. What I proposed does not have any mutual calling as I see it. By using the device interface abstraction, the origin of the responses doesn't matter. It could be a person or a model, and that seems to be a complete separation of the model from the experiment code in my view. That's what I see as one of the important modeling issues - having the model do the same task as a person. The only source of mutual calling would be if do-after-trial-stuff did things to modify the model, and in my view that's no different from a !eval! call in the productions directly. Granted, it may look cleaner, but from a modeling perspective I'd say they're equivalent. I also realize that it's often much easier and sometimes necessary to abstract away some of the details of a trial like that, and for ACT-R 4 that was the standard operating procedure. However, with ACT-R/PM being a part of ACT-R 5 it is possible to model a lot more of the trial and experiment structure. In a sense, one doesn't have to "stop" the human participants between trials, so it shouldn't be necessary to do so with a model either. Again, when it comes to really writing models I know that can be time consuming and not relevant to the purpose of the model, and I'm not trying to say that I think every model needs to account for every detail of the experiment. It's just that with ACT-R/PM attached I think it's now more possible and that may be worth some investigation in general. Back to the question at hand. As Mike and Christian point out, clearing the goal buffer will stop ACT-R/PM. Implementation wise, I'd suggest -goal> instead of !pop! in ACT-R 5 because that's "kosher" ACT-R 5 syntax. One thing that you will need to do however is make sure that you set the ACT-R/PM parameter :auto-dequeue to t because the default is nil, and in that situation it will prompt you for a response before returning. As Christian pointed out though, that's an oddity of the current ACT-R/PM because indeed there can be productions without goal buffer tests that should still be able to fire when the goal is clear. At some level all that's really necessary is to just change the state so that none of the productions will match and the call to pm-run will return. So, there are lots of other ways that can be accomplished, but without the details of your model it's hard to make a good suggestion. As for the issues about the future of things, I'm working on the specification of the new scheduler at this point. One of the things that's in there is the notion of a breakpoint, so it will be possible to schedule "stops", at least as things are starting to take shape with 6 for now. How that will interact with productions is still to be decided, so that's something for future discussions. Dan From r.m.young at herts.ac.uk Wed Oct 8 04:22:39 2003 From: r.m.young at herts.ac.uk (Richard M Young) Date: Wed, 8 Oct 2003 09:22:39 +0100 Subject: [ACT-R-users] stopping pm In-Reply-To: <3F82D111.7010806@uni-bayreuth.de> References: <3F829D4F.8000004@uni-bayreuth.de> <1912920.1065521614@whatever.psy.cmu.edu> <3F82D111.7010806@uni-bayreuth.de> Message-ID: Just a small comment on this matter of stopping Act-R models, from a *teaching* perspective. I've just done my 2nd week class in my final-year undergraduate course on cognitive modelling, and we ran right into this issue of stopping. Dan characterises well what seems to be the style in the Act-R tutorial material when he says: >all that's really necessary is to just change the state so that none >of the productions will match It can be fairly confusing for beginners as things stand. The first model (count) finishes by setting the STATE attribute of the goal to STOP. So of course the model stops. Well, no, it's not that simple. I asked the class to see what happens if the rule is changed to set the STATE to FLUMMOX or virtually anything else, and of course it still stops. In the second model (addition), considerable ingenuity is used to choose a stopping condition. I don't have the model in front of me as I write, but it's something like setting the COUNT attribute to nil while leaving the SUM attribute non-nil, and it turns out that particular combination prevents any rule from firing. Aside from being opaque and confusing to beginners, one of the problems with using this kind of ingenuity to stop the model is that it isn't stable over changes or additions to the model. Make certain changes, and the model will no longer halt cleanly, or perhaps at all. I agree with just about all the sentiments expressed in the discussion so far: - clean separation of model code from the environment code; - people don't actually "stop", so neither should Act-R; - but in practice, especially with small tutorial models, they can't be expected also to model Ss getting on with the rest of their lives. I didn't know that the !stop! command still existed. If it were renamed to be more suggestive of a "that's all for now folks" -- maybe !end-experiment!, or !resume-your-life! -- I would prefer it in the tutorial examples, despite the theoretical objections to the !syntax!. Any chance of getting agreement on this, and getting the tutorial code changed? Best, -- Richard From Wolfgang.Schoppek at uni-bayreuth.de Wed Oct 8 06:02:53 2003 From: Wolfgang.Schoppek at uni-bayreuth.de (Wolfgang Schoppek) Date: Wed, 08 Oct 2003 12:02:53 +0200 Subject: [ACT-R-users] stopping pm In-Reply-To: References: <3F829D4F.8000004@uni-bayreuth.de> <1912920.1065521614@whatever.psy.cmu.edu> <3F82D111.7010806@uni-bayreuth.de> Message-ID: <3F83E0CD.7020000@uni-bayreuth.de> Acknowledging all the efforts of making ACT-R as veridical as possible, I think we should keep in mind that we don't simulate humans, but certain aspects of human cognitive processing. So discussing if a !stop! command would make ACT-R too artificial seems odd to me when I consider what high level of abstraction ACT-R models have (I'd even say, should have!). So what about motivation, emotion and the huge amount of experiential knowledge? I don't want to plead for a complete coverage of all these issues in ACT-R but rather to adjust the scale. So I think a !stop! command pertaining to (pm-run) would be more useful than harmful (btw: it would make debugging much easier). As for the !bang! syntax, I think we would reduce the sphere of possible ACT-R users (and uses) dramatically, when we eliminate it. Many models are explorative, (and sometimes a rough explorative model can be more informative than a model that was painfully tuned to one data set). In such models one needs the shortcuts permitted by !eval! and !bind!. -- Wolfgang ----------------------------------------------------------------- Dr. Wolfgang Schoppek Universitaet Bayreuth Tel.: +49 921 554140 http://www.uni-bayreuth.de/departments/psychologie/wolfgang.html ----------------------------------------------------------------- From db30 at andrew.cmu.edu Wed Oct 8 12:11:06 2003 From: db30 at andrew.cmu.edu (db30 at andrew.cmu.edu) Date: Wed, 08 Oct 2003 12:11:06 -0400 Subject: [ACT-R-users] stopping pm In-Reply-To: References: <3F829D4F.8000004@uni-bayreuth.de> <1912920.1065521614@whatever.psy.cmu.edu> <3F82D111.7010806@uni-bayreuth.de> Message-ID: <95366109.1065615066@whatever.psy.cmu.edu> --On Wednesday, October 08, 2003 9:22 AM +0100 Richard M Young wrote: > > It can be fairly confusing for beginners as things stand. The first > model (count) finishes by setting the STATE attribute of the goal to > STOP. So of course the model stops. Well, no, it's not that simple. I > asked the class to see what happens if the rule is changed to set the > STATE to FLUMMOX or virtually anything else, and of course it still > stops. In the second model (addition), considerable ingenuity is used to > choose a stopping condition. I don't have the model in front of me as I > write, but it's something like setting the COUNT attribute to nil while > leaving the SUM attribute non-nil, and it turns out that particular > combination prevents any rule from firing. > > Aside from being opaque and confusing to beginners, one of the problems > with using this kind of ingenuity to stop the model is that it isn't > stable over changes or additions to the model. Make certain changes, and > the model will no longer halt cleanly, or perhaps at all. For reference, the production mentioned is this one: (P terminate-addition =goal> ISA add count =num arg2 =num sum =answer ==> =goal> count nil ) Which indeed is unclear as to why it terminates the addition. I think that's the only model remaining in the tutorial that doesn't have a state slot in the goal. There are a couple of issues with that, and I think it gets at what is in my observation the most difficult concept for new modelers - state management, or writing the productions so that they operate in a desired sequence, not just how to stop it at the end. The production above shows how things use to be in all the tutorial models. The "state" was implicitly determined by the contents (or lack thereof) in the slots of the goal. That was extremely opaque and confusing as you point out, and not only for beginners either. To make that easier for teaching we moved to the explicit state slot in the goals for the tutorial (why that model wasn't changed I don't know). That does make it easier to read the given models. However, it doesn't seem to have helped a lot when it comes time for students to build their own models, and, in addition to feeling artificial, it can be problematic when using spreading activation because the extra slot has an impact that takes some extra care to handle. Also, by having it in all the tutorial models it sort of promotes a particular style of modeling which isn't what one is likely to find when looking at published models. So it seems to me that neither extreme seems to be ideal, and both are still lacking with respect to the issue of teaching new modelers. I don't know what the right solution is, and comments from others, especially those who have taught the material, would definitely be appreciated. > I didn't know that the !stop! command still existed. If it were renamed > to be more suggestive of a "that's all for now folks" -- maybe > !end-experiment!, or !resume-your-life! -- I would prefer it in the > tutorial examples, despite the theoretical objections to the !syntax!. > It's a little tricky actually once RPM gets thrown into the mix, and that's shown by the way that the "goal clearing stop" works now. By default, it prompts to ask whether you want to complete the pending actions first or just stop immediately. Just stopping immediately after the production isn't always a good thing because there may be actions that were initiated by the production (like a key press) which take additional time that presumably should also be allowed to complete before stopping. Generally, it is just the production system that one wants to stop, and I actually like the feel of the goal clearing mechanism, though not it's current implementation. When the task is done, one clears the goal that was trying to accomplish the task. It seems to fit nicely with the models that perform repeated trials by creating a new goal at the end of one to prepare for the next. It also avoids the need for a special operator to stop things which I think would help reinforce the notion of model "state" for beginners. Thus, I would propose that, particularly for the tutorial, the way to stop a model is with "-goal>" on the RHS. There is still the issue that productions don't need to test the goal, and thus it wouldn't always stop things. So there should still be some programmatic mechanism(s) (and there are such things being designed into ACT-R 6), but from a teaching standpoint -goal> feels good to me. Again, comments and suggestions are welcome. > Any chance of getting agreement on this, and getting the tutorial code > changed? It's not likely that the ACT-R 5 tutorial will be change at this point, but discussion of these issues will be beneficial when it comes time to update things for ACT-R 6. Dan From db30 at andrew.cmu.edu Wed Oct 8 15:29:08 2003 From: db30 at andrew.cmu.edu (db30 at andrew.cmu.edu) Date: Wed, 08 Oct 2003 15:29:08 -0400 Subject: [ACT-R-users] stopping pm In-Reply-To: <3F83E0CD.7020000@uni-bayreuth.de> References: <3F829D4F.8000004@uni-bayreuth.de> <1912920.1065521614@whatever.psy.cmu.edu> <3F82D111.7010806@uni-bayreuth.de> <3F83E0CD.7020000@uni-bayreuth.de> Message-ID: <107247934.1065626948@whatever.psy.cmu.edu> --On Wednesday, October 08, 2003 12:02 PM +0200 Wolfgang Schoppek wrote: > Acknowledging all the efforts of making ACT-R as veridical as possible, I > think we should keep in mind that we don't simulate humans, but certain > aspects of human cognitive processing. So discussing if a !stop! command > would make ACT-R too artificial seems odd to me when I consider what high > level of abstraction ACT-R models have (I'd even say, should have!). So > what about motivation, emotion and the huge amount of experiential > knowledge? I don't want to plead for a complete coverage of all these > issues in ACT-R but rather to adjust the scale. So I think a !stop! > command pertaining to (pm-run) would be more useful than harmful (btw: it > would make debugging much easier). As for the !bang! syntax, I think we > would reduce the sphere of possible ACT-R users (and uses) dramatically, > when we eliminate it. Many models are explorative, (and sometimes a rough > explorative model can be more informative than a model that was painfully > tuned to one data set). In such models one needs the shortcuts permitted > by !eval! and !bind!. -- Wolfgang Absolutely. I'm not trying to say every model should account for everything, and I wasn't trying to argue that a stop command was artificial in and of itself. I wanted to point out that there are other mechanisms in the system that can accomplish what it appeared like you needed, and that it could be considered in the context of the overall modeling objective instead of at the "programming" level. How one chooses to do so is still up to the user, but just because code occurs in functions instead of the productions doesn't necessarily mean it is not part of the "model". Which is a distinction I think gets blurred quite often because the assumptions and shortcuts used do have an impact on the results of the model, but are often not discussed in that context if at all. As to the scope of the system, indeed, it's not at a point of simulating humans. But as a tool, one can apply it to essentially any level one is interested in, and there actually are people working on issues like those you mentioned (motivation, emotion, and experiential knowledge) within ACT-R. So it's not out of the question to think that someday those could become just another part of the system which one could use for modeling, and that perhaps someday it could be applied as a much broader simulation of humans. There is certainly a need for adequate debugging tools, and ACT-R 5's addition of ACT-R/PM "out of the box" has definitely exposed some areas that could use more work. One thing I think we need to be careful of however is feature creep, and instead of adding lots of little special case functions provide general and robust tools with good documentation. That's not to say there won't be special case operations, but having too many commands can get in the way and lead to confusion of the user. For instance, I can thing of four "easy" ways (*) to find out what chunk is in the goal buffer (not counting using the environment). They all return something different, and none of them can be extrapolated to find out what's in the visual buffer. That doesn't seem like an ideal situation to me. Finally, nobody as far as I know has suggested that the functionality of !eval! or !bind! be removed. The issue is one of syntax - how are they going to be represented in ACT-R 6 productions? The proposal on the ACT-R 6 page (http://act-r.psy.cmu.edu/act-r6) has one such mechanism which eliminates the need for the special bang operators. The response to that was mixed at the Workshop, and there's still a lot of work to go in designing ACT-R 6. So how things will eventually look is still up in the air, but there is a definite need for that type of functionality and it will be there one way or another. Dan * For those that are curious, I've listed the ones I thought of below, and there are probably others. I've put some space in for those that want to try to think of them without looking. :) . . . . . . . . . . . . . . *wmfocus* holds the WME itself. (goal-focus) will return the name of the chunk. (buffers goal) will return a list containing the name of the chunk. (dm) prints out all of the chunks, and one can look for the item with the ** marker to find the goal chunk. The return value is the list of all chunk names, which with RPM loaded is always larger than just the goal chunk. From nc at alum.mit.edu Fri Oct 10 14:22:01 2003 From: nc at alum.mit.edu (Nick Cassimatis) Date: Fri, 10 Oct 2003 14:22:01 -0400 Subject: [ACT-R-users] Call for Interest in AAAI Fall 2004 Symposium on "Achieving Human-Level Intelligence through Integrated Systems and Research" Message-ID: <003b01c38f5b$65e9c180$fb50fa84@nickcog> We are seeking expressions of interest in participating in a AAAI 2004 Fall Symposium on a promising new approach to artificial intelligence research we call "Achieving Human-Level Intelligence through Integrated Systems and Research". At the end of this message is a brief description of the symposium. If you would potentially be interested in attending please respond with your name and affiliation to nc at alum.mit.edu before October 15. This is only an expression of interest and there would be no obligation to participate. The symposium would take place in Washington, DC in November of 2004. We especially hope to hear from cognitive modelers. Nick Cassimatis Patrick Winston ======================================================= Achieving Human-Level Intelligence through Integrated Systems and Research Achieving human-level artificial intelligence will require systems and research to be integrated from not only several subfields of the artificial intelligence research community, but from other fields interested in cognition. We propose to gather researchers working across the boundaries of their subfields to explore new computational techniques and research methodologies for integrating research results to produce more intelligent systems. There has been substantial progress in some of the subfields of Artificial Intelligence during the past three decades, but the field overall is moving toward increasing subfield isolation and increasing attention to near-term applications, retarding progress toward comprehensive theories and deep scientific understanding, and ultimately, retarding progress toward developing the science needed for higher-impact applications. Some recent trends in artificial intelligence research, for example cognitive robotics and computer vision research informed by human visual processing, have begun to reverse this trend towards fragmentation. Because the human mind is both an example of an integrated system that uses multiple representational and computational techniques and because it by definition exhibits human-level intelligence, these researchers have found it useful to look towards fields such as linguistics, psychology and neuroscience for inspiration and constraints on their theories. We propose to gather together researchers interested in achieving human-level artificial intelligence through integrated systems and multi-disciplinary research to discuss recent progress and proposed future work towards this goal.