* students requested glossary. * will want to move to main soar html help files. * The other change I think is needed, but I was unable to do (see note in the the "to do" file I sent you), is to improve the Impasse diagram in section "Chunking". * The wording under the drawing (but part of the diagram) could be improved. Probably want to move it out of the diagram, for a start. The line "Arrow sets going into a node ..." could perhaps be explained better, something more like "The set of arrows pointing into a node correspond to the conditions of a rule that fires to produce the node." * Is there a pointer to answers for Exercise 9 anywhere? should have a trace available., but soar7 is broke * Several of the Soar variables, e.g. , showed up in the tutorial as the literal <x>. Fixed within text by using "<x>" . * In some cases I find the extra spaces after italicised items a pain on the eye. In some cases the solution is to take advantage of the punctuation. If the italicised word is followed by a comma, say, then move the comma outside of the italics and you don't need the extra space. * The not-equal symbol "<>" seems to cause format to terminate prematurely. This is bad news, as it greatly complicates the process of display productions. I've fixed it in the one place it occurs in the tutorial, by using the sequence ...<\xmp><pre>&lt;&gt;<\pre><xmp>...newline... . But what a pain! * The problem mentioned above with the <> symbol relates to something I've never been clear about, which is how students are meant to view the listings. The instructions in various places imply that they should view them through the web browser, but that surely won't work? For working live across the net, the browsers can certainly be used to pull down the listings, but not for looking at them. - Is there a kind of 'protocol' (http, ftp, file, ...) that can be used to grab a text file and automatically put it up in a simple text viewer? If you load a PostScript file via an "ftp://" link, if you're set up right it will automatically open a PostScript viewer on the loaded file. Is there anything similar for plain text files? If not, students will have to be told about how to use the Web browser to load the file into a local file, and then open SimpleText on it. * In file analogy/listing/contents.html, and also hungry-thirsty/... likewise, put instructions (or if they're elsewhere, a clearly described pointer to them) for how to get hold of the listings and how to view them. * In analogy/tutorial.html and hungry-thirsty/..., at the top where it says "If you are viewing this from a web site", need to explain ... Oh, OK, maybe I'm making too much fuss, maybe most of the instructions are already there. But I would suggest (1) adding another sentence to explain to use SimpleText to actually view the code, and (2) repeat the instructions in both listing/contents.html files. hungry-thirsty/overview/full.html * In the Big Picture of the Soar architecture, I think some changes need to be made, as the present version is positively misleading in some respects. My main complaint is that the heavy arrow suggest that the major processing loop is from WM to chunking to LTM to WM. I would suggest the following: (1) The arrows are anyway too heavy for the diagram. (2) A major arrow from LTM to WM, fine. (3) There needs to be a flow the other way, from WM "to" LTM, perhaps in the form of an "eye" looking at the contents of WM and connected back to LTM. (4) Should it be "long term recognition memory", or "production memory"? (5) The learning route, from WM to Chunking to LTM, needs to be made with arrows that are perceptually obvious as secondary routes, not primary ones. But in fact, Chunking isn't a storage box, in the way that WM and LTM are, so it doesn't really make sense. Would be better to have a curved arrow going (at the right hand side) direct from WM to LTM, labelled "chunking". It would be worth taking a close look at other people's corresponding overview diagrams, Soar-on-a-slide, and so on. I'd have a go at this myself, but I'm not sure about the technology. What does one use to create the GIF diagrams? * In section "Resolving impasses", there's a reference to "and gives rise to a characteristic kind of chunk". There has been no mention of chunking up to this point, so we have another sequencing problem. I've fixed it temporarily. Frank, all these sequence problems stem from the last reorganisation we did, when we moved away from the old scheme which first did a quick tour through rules, preferences, decisions, and chunking, then moved onto exercises, and only then went through the topics in the detail that we cover. My preference would be to return to that scheme -- perhaps re-thought in light of the possibilities offered by hypertext -- but it would now be a lot of work. * In section "Chunking", the impasse diagram was never intended to be stand-alone. It might benefit from a re-design. One thing might be to indicate more clearly that the middle section is the subgoal (at present the word Impasse looks more like a heading for the diagram), and perhaps have dotted curving lines connecting the crucial nodes to their appearance in the chunk. But that may make it very spaghetti-messy. The chunk needs a bit of vertical separation from the diagram itself. * In section "Rule templates", I've made some changes off the top of my head to bring it more into line with NNPSCM, but I'm not happy with the set there, and this really needs more thought. If we had a real set of templates available, it would be nice to be able to point to them. * Entry for "Soar manual 6.1" should probably be replaced by a short file that explains briefly about the state of play with Soar6 and Soar7 manuals, and has pointers to them (remember: Soar7 "man" is not a manual!), and instructions for getting hold of them. * Is the FAQ still local to the tutorial? At present, it leads to a skeleton file. Should be fixed. * Add to the references, the multiple book reviews in AI journal and in BBS. (The BBS reference is sort-of there already, but could be more explicit. In general, it would be helpful to add a short para about each of the references cited. Sigh! A job for RMY. analogy/exercises/1.html * needs to say somewhere "and run the program". * I don't have the handout version of the exercises here, but doesn't it somewhere say something like "and compare with Trace 1", or whatever? If not, the answer should do that? Sorry, I guess this one doesn't go to Trace 1 after all. analogy/answers/1.html * See immediately above. There should be a little bit of content here, even if it's just to say that the program should run and should produce a trace like that in Trace 1, or whatever. (Sorry, not Trace 1.) analogy/exercises/4.html * Needs better layout, and to recover some of the structure that's present in the printed version of the exercises. In particular, needs some numbering imposed for the several exercises included. analogy/answers/4.html * Needs syntax updated to NNPSCM & Soar7. * For viewing on a screen, diagram should be redesigned to be smaller, and in particular with less vertical white space. Should easily be able to fit all on screen at once. * This is not immediate priority for now, but I have an idea for how to present this answer slightly more interactively. Start with the same kind of thing we have now, which is presumably a diagram. After it, say "If you want to examine this rule in more details" or "want to know more about how this rule works" click here. Takes us to a new page, which says just "Click on the part of the rule that you want to find out more about", and there is then the rule written again (but just the rule, not the surrounding gumph), but this time not as a diagram but as text. (Probably a bit of a pain to construct, because of the angle brackets, but not impossible for a one-off.) Different bits of the rule are links that lead to more detail about that part. (If this is done within a single file, each bit of explation needs to be followed by a link "Back to the whole rule" linked to top of file.) If I have time, I'll have a go at this. ** OK, I've done it!** Take a look at the revised analogy/answers/4.html, and let me know what you think. But it STILL NEEDS THE DIAGRAM UPDATED TO THE SOAR7 VERSION. I've put the new version of the rule in file analogy.4.rule.s7. soar-help/contents.html * Needs to be updated to Soar7 command set. * Check that all pointers lead to the right place, and lead to something with appropriate content. These are (some of) the files I haven't yet looked at soar-help/execution.html hungry-thirsty/exercises/contents.html hungry-thirsty/traces/contents.html hungry-thirsty/overview/references.html hungry-thirsty/exercises/1.html hungry-thirsty/answers/1.html hungry-thirsty/exercises/2.html hungry-thirsty/answers/2.html hungry-thirsty/exercises/3.html hungry-thirsty/answers/3.html hungry-thirsty/exercises/4.html hungry-thirsty/answers/4.html hungry-thirsty/exercises/5.html hungry-thirsty/answers/5.html hungry-thirsty/exercises/6.html hungry-thirsty/answers/6.html hungry-thirsty/exercises/7.html hungry-thirsty/answers/7.html hungry-thirsty/exercises/8.html hungry-thirsty/answers/8.html hungry-thirsty/exercises/9.html analogy/exercises/2.html analogy/exercises/3.html analogy/answers/1.html analogy/answers/2.html analogy/answers/3.html From Richard 9/11/94: CONTENT & RE-ORDERING GLITCHES #11 (The Context Stack), 2nd bullet mentions "Decision Cycle", but the DC isn't introducted until later? #29 (Chunking II: Implications), 3rd bullet mentions justifications & persistence, but these aren't introduced until much later? #30 (Multiple Spaces). 2nd bullet says tree or web, but I think this is misleading & potentially highly confusing for the students. The multiple spaces form a *stack* at any time. The tree/web only comes from a more abstract view that collapses across time. I'd suggest simply noting the connection between spaces and the context stack. #36 (Further Readings) Should the list include the Dutch Soar book? We may have already discussed this and decided against ... SURFACE #9 (Soar as a Problem Space Architecture), 2nd line, make -> made. #19 (Production Rules: Syntax), on RHS op name should be "paint", and maybe also the blurb at the top (else production name should have "repaint"). #20 (Production Rules: Syntax Shorthand), title bar has mixed font. #23 (Practical 5): this is the first of several where part of the content of the OHP has slipped into the title bar. #27 (P-6) likewise. #28 & #29 (Chunking) I'd suggest 1 and 2 instead of I and II in the title bar. #29 (Practical 7) has slipped onto the preceding page. See also comment on #23. #31 (Practical 8) like #29. #32 (Practical 9) like #29. But ... for several of the Practicals, if there is room on the preceding page, they don't need a slide of their own? But then it needs to be formatted properly, not with spurious title bars at bottom of page. From: Richard Young <rmy@mrc-apu.cam.ac.uk> To: ritter@Psychology.Nottingham.AC.UK Subject: Post-mortem Date: Mon, 14 Nov 94 15:38:03 GMT 1. Terms like "clover" and "paddle" regularly cause problems (in this case, a couple of people at least typing in C-L-O-V-E-R). The description must be made explicit, and not relying upon the students guessing what's in our heads. 2. Similarly, the "p <ID>" caused problems. Please change it! It has problems every time. Also, you often talk about IDs when you're talking, and I don't think most people know what you mean (the abbreviation is not used in Europe, and I suspect most non-native speakers hear something like "ideas"). 3. We could be more explicit about approaching the tutorial via the levels KL -> PSL -> SL. 4. We could introduce the idea of DCs by focussing on operator choice rather than via the general context slots. That will also fit better with NNPSCM. 5. In Practical-2 (and elsewhere), we should be tracing stuff on the goal, in particular ^desired -> ^hungry no. 6. I have mixed feelings generally about the large-scale reordering you did this time. I think it led to several places where the students were being told things they couldn't yet understand, and also pushed them onto the machines before they were ready. See also #19 below. There are also several local casualties of the reordering, mentioned individually. If it were me doing the first part next time, I'd be tempted to revert to the previous ordering. It's not that it was so bad this time, just that the previous version was better and more carefully checked through. But maybe I'd also try to keep some of the saving of duplication. 7. Ought we to add documentation strings to all the productions in both h-t and analogy? 8. Slide #26 (resolving impasses) depends on chunking, which is now not mentioned until later! 9. The diskette should avoid having a sub-directory for Analogy. 10. My analogy exercises need to be much more explicit about instructions, more spread out, making clear things like a new Soar before Ex.2, and generally with less messing around with temporary files. 11. My favourite Ex.12 is still too hard! Need a sequence of more explicit hints? (FER's notes:) 12. Chunking is not just caching, and influences the representation. Learn ??? better than All -> may be bad. (?) 13. Hook micro-theories into Soar. FOK: parts recognition. 14. Listening to Fortran. 15. An op must be learnable, or it's not an op! We got fewer feedback forms than usual, only 7 (copies will be on their way to you). But the suggestions were far more specific than before, with considerable consensus: 16. Clearer instructions on Analogy (see #10.) 19. The purposes of some of the exercises is not clear, nor their linkage into the "talk" part of the tutorial. (I think this applies to both parts of the tutorial, with some explicit FER and RMY mentions, but also some are unclear.) From: "Frank E. Ritter" <ritter@vpsyc> To: ritter@vpsyc Subject: print ~/res/soar/tutorial/mhb-comments.txt Date: Tue, 29 Aug 1995 21:38:58 +0100 Moritz Bauwman 4-Aug-95 Comments on the Soar tutorial CS Student, TUB xx courses in CS, most importantly, prologue, etc. I. The hungry-thirsty model: in soar-overview.html: (5 min) What are WM elements working memory ! (should be mentioned before) soar-fundamentals.html: (2min) soar-theory.html: (2min) soar-ps-impasse.html: (5min) does soar really invent a new operator, when there is non which can be applied? (would be interesting to know how) ht-exercise1.html: (10min) 1)(towers-of-hanoi) stare at it's beauty? unless you give soar the rules how to move the pieces and give it a goal it won't do anything 2)&3) I don't know exactly what the difference is. In my eyes knowledge is represented as productions or chunks. But I'm not sure about this. 4)I don't want to read them, but I want them a little bit more explained. soar-knowledge.html: (3min) without control knowledge will soar be able to solve even simple problems? e.g. given that there are five different states p1,p2,p3,p4 and p5, five operators op1,op2,op3,op4 and op5 which look like: op1(p1)-> p2 op2(p1)-> p3 op3(p2)-> p4 op4(p4)-> p2 op5(p3)-> p5 (verbally: when you are in p1 and use op1 then you'll be in state p2 afterwards) and soar's goal is to get from the initial state p1 to the final state p5 than it might occur that soar takes the wrong operator op2 in the beginning and will never reach p5. If soar would use width first search it will reach it's goal in any case (or if would recognize loops as faults). soar-default-rules.html: (2min) soar-symbol-level.html: (10min) you broke your convention to abbreviate Problem-space PS (P could be Production as well) what exactly is the context stack? does it contain the current goal to be archieved? I haven't seen any impasse arise during exercise 1 or which behaviour is reffered to? soar-wm-elements.html: (3min) is the order of the attributes important? if so, it shouldn't, because they contain the same information. to put it in another way: does soar refers to (x35 ^isablock ^colour red ^size large) and (x35 ^colour red ^size large ^isa block) as the same element in WM? ht-exercise2.html: (15min) I still do not understand this page! (sorry) - how can you examine the trace? - how can I get a list of the problem-space elements? - ... - how can you see the current goal and current state and witch op was applied soar-prefs-and-decisions.html: (3min) I don't understand how they vote for feasability,excusivity,... Normally they don't know, or is the vote programmed? preferences.html: (2min) ??? (Explanation is quite short!) see above! ht-exercise-3.html: (20min) watch :firings - preferences on (it did not work!) Expected 'on' or 'off' for new watch setting watch :firings - preferences on ---------------^ > should be watch :firings on > watch :preferences on > > finally made it with watch :firings-preferences on ( well, the colon is at a very funny place) Followup-questions: (45min) - it took me quite a long time until i entered the right commands to produce the trace - i tried to comment the trace (see right hand side the >...) so you can see what i thought this model would do. 1) the trace =>WM: (2: S1 ^superstate nil) > what is this for? =>WM: (1: S1 ^type state) > declares S1 to be > a state ? 0: ==>S: S1 > fills the state > slot with S1 ? --- Input Phase --- > side effects? =>WM: (6: E1 ^text-output-stream *standard-output*) =>WM: (5: E1 ^text-input-stream *standard-input*) =>WM: (4: S1 ^text-environment E1) =>WM: (3: S1 ^io I1) --- Preference Phase --- Firing default*top-goal*elaborate*state*name*top-goal*top-state > could be 'find top > goal' but I don't > see the idea > behind this name Firing ht*propose-space*ht > propose a ps --- Working Memory Phase --- =>WM: (12: D1 ^hungry no) > desire not to be hungry =>WM: (11: P1 ^name hungry-thirsty) > name of whatever =>WM: (10: S1 ^desired D1) > S1 desires n. hungry =>WM: (9: S1 ^problem-space P1) > P1 is ps for S1 =>WM: (8: S1 ^name top-goal) > sets name to top-goal? =>WM: (7: S1 ^name top-state) > s. above (but useless?) --- Output Phase --- --- Input Phase --- --- Preference Phase --- Firing default*top-ps*elaborate*state*io-state > just for i/o (side-effect) Firing default*top-goal*elaborate*state*problem-space*desired > find out desired > ps ? Firing ht*propose-state*ht > proposes a state? > which one? --- Working Memory Phase --- =>WM: (17: S1 ^hungry yes) > in S1 you're hungry =>WM: (16: S1 ^thirsty yes) > " " thirsty =>WM: (15: S1 ^name ht-state) > what is the ht-for? =>WM: (14: P2 ^name top-ps) =>WM: (13: S1 ^io-state S1) > no idea (me) <=WM: (7: S1 ^name top-state) <=WM: (8: S1 ^name top-goal) --- Output Phase --- --- Input Phase --- --- Preference Phase --- Firing ht*propose-op*drink > propose oper. drink Firing ht*propose-op*eat > propose oper. eat Retracting default*top-ps*elaborate*state*io-state > why are there any > states to be > retracted Retracting default*top-goal*elaborate*state*problem-space*desired > well perhaps it > knows by now the > appropriate ps --- Working Memory Phase --- =>WM: (21: S1 ^operator O2 +) > op. is feasable =>WM: (20: S1 ^operator O1 +) > " " " =>WM: (19: O2 ^name eat) > I don't know the =>WM: (18: O1 ^name drink) > need of ^name <=WM: (13: S1 ^io-state S1) > i/o ? <=WM: (14: P2 ^name top-ps) > ps is p2? --- Output Phase --- --- Input Phase --- --- Preference Phase --- Firing ht*compare*eat*better*drink > it has compared > the states and > thinks that eat is > better than drink --- Working Memory Phase --- --- Output Phase --- --- Input Phase --- --- Quiescence Phase --- =>WM: (22: S1 ^operator O2) 1: O: O2 (name: eat) --- Input Phase --- --- Preference Phase --- Firing ht*apply-op*eat > it says then eat... chomp chomp... > yumm, yumm --- Working Memory Phase --- =>WM: (23: S1 ^hungry no) > hungry changed to no <=WM: (17: S1 ^hungry yes) > this was hungry before --- Output Phase --- --- Input Phase --- --- Preference Phase --- Firing ht*terminate*eat > stop eating Firing ht*evaluate*state*success > new-state is a success? Retracting ht*propose-op*eat > remove proposal --- Working Memory Phase --- =>WM: (24: S1 ^success D1) > succeeded in D1 <=WM: (21: S1 ^operator O2 +) > because of O2 > (which is removed) --- Output Phase --- --- Input Phase --- --- Preference Phase --- Firing default*top-goal*halt*state*success > halt state, > because of success goal for S1 achieved Firing default*top-goal*halt*success > s. above ht-state achieved Firing default*monitor*goal*success > I think the goal > was monitored! Goal ht-state succeeded. Retracting ht*compare*eat*better*drink > the comparison is retracted System halted. Question 2: well, soar looks which operators are feasable, then it tries them and looks, whether the goal has been archived or not. soar-production-rules.html: (2min) so soar-productions can modify wm directly? so the rules fire in parallel but there may be a sequential order because some rules only fire, because of modific. in wm? had a look at the source-code of ht.s6: (10min) problems: -^impasse ^superstate nil in ht*propose-space*ht was not clear for what reason there exists ht*terminate*eat ? should be really explained! soar-rule-syntax.html: (8min) <bla> it's nowhere mentioned that these are variables (or objects, they are just used). this attribute ^name is it a must in soar, or just a convention? to me it looks like the search key (but I could call it ^blah as well). ht-exercise-4.html: () examining preferences Soar> preferences s1 operator Preferences for S1 ^operator: Acceptables: O1 (name: drink) + ht-execise-5.html: (10min with cut and paste) see file ~mhb/soar/htm.s6 ==> why does soar don't succeeds in ~mhb/soar/test.s6 (in my eyes it should) > o.k. it did ;-> soar-impasses.html: (2min) soar-kinds.html: (2min) there should be an example because it's hard to make out what these subgoals would look like. soar-resolving.html: (5min) see above ------------------ using the new soar- tutorial --------------------- ;-) ht2.s6: (long long time ;-) I think that in this example the knowledge is very specified (e.g. all evaluation functions are made in dependence of the goal) It would be more intuitive to say that if ^desired.hungry no that eat would be execellent (otherwise e.g. good) and the same for ^desired.thirsty no... the production rules should be more unified (why aren't they the same)? there is: selection*evaluate*eat but: selection*evaluate*drink*not*thirsty and: selection*evaluate*drink*thirsty the values these productions return also look quite funny to me exercises/6.html: (10min) I found these quite trivial because if your desire is to be thirsty, well then maybe you shouldn't drink ;-) Questions: - that there are two indifferent operators appliable - e.g. ht*eat-better-drink rule because it say's if you are hungry prefer operator eat ! - see obove chunking.html: (5min) I don't think this picture gives you a very good idea what chunking is alike. First it would be interesting what is a WME? - is it e.g. (<s> ^desired <d> ...) where <d> is no seperate WME - or is it like every (<x> ...) line is an own WME? Then I would prefer an example like ht2.s6 (with learn on), used in the figure and not something abstract like A,B,C,D,E,R (in the chunk phase this is not so important, but the rest would be easier to understand). In the Text: - does RHS mean Right Hand Side of the productions (the Actions) ? - and LHS is Left Hand Side (Condition) when I run ht2.s6 I'don't see any justification being created. I thought they are formed even when learn is off. and when you run ht2.s6 with learn on a chunk will be created. -> so what are justifications for and how can you show the use/sense of them. exercises/7.html: (5min) this is a good exercise because you see how the chunk is created, you can understand it and when you run the program the next time you see the chunk firing and giving eat the preference <. Questions: - so the chunk looks very familar. - I'm not sure. maybe I expected the chunk to do the action, but all it did was making eat better than drink (so the impasse is avoided). This is very elegant ;-) template.html: (3min) there is still no explanation for having apply and a seperate production for terminate. what do thes templates look like? exercises/8.html: () I'm not sure what I have to do here. - what stand's this :default for? (it's mentioned nowhere) is its meaning: I'm a default rule. or: use me instead of the default-rule I've asked Gorden but he's not sure, either. persistance.html: (2min) How can you see the difference between rules with o- / i- support? Are there flags like ^sticky yes or something like that, or does soar know because this rule is used from an apply rule, and the other is not? exercises/9.html: (5min) I noticed a slight difference in the description between the last 2 lines. If this is inteded it would be nice to explain this in persistance.html as well. I think it should be " preferences s1 operator" ----------------- cut here ----------------------- Soar> preferences s1 operator Preferences for S1 ^operator: Acceptables: O1 (name: drink) + O2 (name: eat) + Betters: O2 (name: eat) >O1 (name: drink) ----------------------- end ---------------------- ------------------------- general proposal ----------------------- throughout the hole hungry-thirsty model the production: (sp ht*evaluate*state*success (state <s> ^desired <d> ) (<d> ^hungry <val>) (<s> ^hungry <val>) --> (<s> ^success <d>)) is used. In my opinion it would be much more human-like to say well whenever I've got the desired attribute with the desired value in my Top-PS, well then I'm finished. so the following rule would be much more general: (sp ht*evaluate*state*success (state <s> ^desired <d> ) (<d> ^<attribute> <val>) (<s> ^<attribute> <val>) --> (<s> ^success <d>)) Moritz Bauwman 4-Aug-95 Comments on the Soar tutorial "Simple Analogy" Soar Tutorial Version 3" comments and questions CS Student, TUB xx courses in CS, most importantly, prologue, etc. read til exercise 1 (seems to be clear but I'll reread it more critical) models.html: (1min) method.html: (3min) but if there is no implementation for the action soar will run into an endless loop. unpacking.html: (3min) paragraph 2 is not explained too good (I understood what it wanted to say, but I don't think the first sentence is so good). 2. Then we take away some of the knowledge to solve the problem ... add some low-level/generic knowledge which should produce chunks (like the deleted knowledge) to solve the problem ideas.html: (5min) in paragraph 1 there is said, that we have behaviour that occurs without any uncertainty about what to do, and that, given a task, we have rules that specify what action(s) to take. On the other hand these TAM rules are/will be learned by chunking. I was thinking that soar only builds chunks, when it learns something. And in my eyes learning only occurs when you're incertain about what to do next (and you find out). So these sentences are in some way contradictory. perform-space.html: (2min) see above exercises/1.html: (5min) runs fine ;-) but: - e.g I wanted to start an unknown program (e.g. 'x') and soar didn't know what to do. if this perform-space would be fully automatised soar should either ask "sorry is this a <type of program>" or stop. analogy-topspace.s6: (15min) There seems to be only complete knowledge about these for programs, but no analogy rules like mentioned in method.html this explains my but: ... above, but: - when you are doing an analogy-model there should be analogy-rules otherwise you could call the model knowledge-based system. (it's like cheating) action-space.html: (2min) exercises/2.html: (10min) works fine as long as you only start draw or word. but: when you start xl or cg soar will terminate abnormally. Firing action-proposal*initialise Firing monitor*problem-space*nnpscm P: P2(action-proposal) Firing action-proposal*use-analogy*propose 2: O: O1 (use-analogy) 3: ==>S: S3 (operator no-change) Firing default*generic*opsub*propose*space*generic : : : : : : : : : : : : : : : : : : Firing default*select*reject-and-reconsider*failed*operator Firing default*select*reject-and-reconsider*failed*operator 8: ==>S: S7 (state no-change) Internal error: deallocating prod. that still has inst's Soar cannot recover from this error. Aborting... use-operator.html: (3min) this can't explain the above behaviour! use-space.html: (2min) imagine.html: (5min) the figure is only telling what happens if an impasse arises, but it doesn't tell us what happens if no impasse arises (in one of the sub- goals/ sub- PS). exercises/3.html: () Hungry-thirsty tutorial: - Break up into segments of not more than 2-3 pages of info. These should be as self-contained as possible so that the user does not have to flick back to other pages in order to grasp the context. - Retain sequence info by introducing NEXT and PREV icons, together with TOP OF SECTION and MAIN PAGE. These should be at the top and bottom of pages (since they may span more than one screen). - Diagrams that are too wide (i.e. require use of the width scrollbar) should be narrowed, or just made smaller. - Possible introduction of questions at suitable points in the text to make readers think about what they are viewing. - Possible inclusion of graphical maps to show users where they are in the hierarchy, and how much of the tutorial is left. - Put in a link to the full document so that it can be printed. The printed copy won't be as up-to-date as the actual tutorial, as it will be trickier to constantly update. The print-out should, however, include the URL for the tutorial, so that citings of it will be correct. - Addresses of authors should include the HTML "mailto" capability, which (I think) allows you to click and mail. - Include a "What's been updated" page, so that people who have completed the tutorial know which bits they need to review. - Make diagrams interlaced so that you don't have to wait for the doagrams to appear before the text does. Analogy tutorial: - Should incorporate all the hungry-thirsty changes - Will feature the problem space diagrams as the central theme, which will become more complex. These diagrams should allow links so that they can be clicked on for information, code etcetera. How feasible this is I shall find out (since HTML only allows one link per diagram I suspect it will involve breaking the diagram up into small parts and trying to piece these together nicely on the screen). I think perhaps the NEXT and PREV icons should be taken out so that users are encouraged to click on the diagram parts, but you may think differently. I've made the diagrams quite explicit so the user knows exactly where they'll go if they click on certain bits. If the NEXT+PREV icons do go, then I'll put some text in to say how the diagrams should be used. The rules for O-support can be found off my Web page at ftp://centro.soar.cs.cmu.edu/afs/cs/project/soar/member/gap/doc/o-support.Z Or in the Soar6 specification (if you can read Z). Unfortunately they are for the old PSCM style, but they might be useful anyway. The simple rules of both the current O-support strategy and OPERAND are: 1) An operator is dependent upon the state and An operator's components should be able to be built over multiple productions (rather than with a single production). 2) The selected operator can make persistent changes to the state. 3) Persistent changes should not be able to be made to architectural objects. This is just the operator slot today. With regard to current state, yes you're quite right, the current state at any context level is the thing that fills the S slot, and its problem-space, if it has one, is its ^problem-space attribute. But, there are a couple of difficulties with this: (a) It's a weak notion. In NNPSCM, each context has exactly one filler for the S-slot, put there by the architecture and never changed. So it's more like "THE state" than "the CURRENT state". Also, ^problem-space is no longer a special attribute, and there may not even be one. (b) Remember that if the goal/context stack is say 3 levels deep, then there are 3 states around, one for each context. If we're not careful, the phrase "current state" can sound as though it's trying to refer to some particular one of those, whereas of course they're all "current". My own taste is to confine the phrase "current state" to meaning something like a shorthand for "the current configuration of the state", i.e. meaning its *domain content* rather than the identity of the slot filler. Notice, that is what is changed by an operator application. But I guess I have to admit that that can be confusing too. Does that make any more sense? ------------------------- ************************************************************** ************************************************************** ************************************************************** DONE DONE DONE DONE DONE DONE DONE DONE DONE DONE DONE ************************************************************** ************************************************************** ************************************************************** ************************************************************** Need to watch out that files edited on a mac, under unix must use the emacs command "M-x replace-string C-q C-m C-q C-j" to make them readable. Done: These are (some of) the files I haven't yet looked at soar-help/rules.html * Do we want the Author Information link, given that the 2-3 people are individually listed, with links to their home pages? Maybe something basic, because this tutorial may be used off-line. In which case, the author info needs to be added. (Or else make both the Frank and Richard links go to "author information", and have optional and clearly indicated links to web home pages from there?) We want author information on the first page. The other file has been deleted. * The Other Soar People link goes to an uninformative list of Japanese names. Do we want this link? If so, what should be on it? The present file should definitely be removed. This has been removed, and the soar-faq inserted. soar-help * What are all those cacheXXXXX files? Deleted 'em. * There were several cases where the name of an 'anchor' was missing its closing double-quote. This is dangerous, as whole sections of the tutorial get dropped! Let Richard do this. * Remove backup files (ии~) from folders. Noted in pst-index section on releasing tutorial to do this. In index.html * In the comments at start of file, both the <pre> and <xmp> are causing output to appear at start of page. They need somehow to be protected, either by escaping the command, or by a stronger comment that extends to the whole line. DONE, sort-of, by using 'pre' instead of <pre>, etc. * Renamed to be pst-index.html * need to get default.s7 into this directory. fixed, fer. * I *think* there are a whole load of files (fundamentals.html, impasses.html, ...) whose contents have now been incorporated into the main full.html file. If so, they are now out of date, and should be removed. That applies to both hungry-thirsty and analogy. * The pointers from analogy/listing/contents.html need to be changed to point to the .s7 files. fixed, fer. * needs to be put on man path /rapidd/part2/utils/soar/tcl/soar-7.0.0.beta/doc/man * need to note the tcl paths in my .cshrc file as changes you need created a shell file to do all this. * At the very end of "Soar as a problem space architecture", the term 'impasse' is introduce, then the section ends. The narrative implication is that we're now about to be told about impasses, but that doesn't in fact happen until much later. I've added an optional, and well guarded, lookahead link, but you may want to revise it. I think this is one of several places where there is a problem of sequencing. It's not really clear that we need to raise the question of "what happens if .." at this point at all. fine, leave it in. * By the section "Knowledge as production rules", sequencing problems are getting serious again. There is talk about decision cycles and preferences, neither of which is introduced until later. I've done some patching up, e.g. changing "decision cycle" into "major cycle" + forwards reference, but really the basic sequence needs re-thinking through. fine, leave for now. * For Analogy, you say that something works only if you "access it through the Internet". I know nothing about that side of it, but it does seem extraordinarily odd. Surely Netscape or Mosaic treats the pages the same whether they're local or remote? Would it make any sense to "go through the Internet" back to one's own machine? Are you sure about this? No longer know what this refers to, can't find it. All exercises/N.html files: * Change the names and pointers to .s7 files, and where necessary update the exercise content to Soar7, e.g. commands and rule syntax. All trace files: * Need to re-run under Soar7 to get new traces. * At least in Mosaic, the Back command doesn't work for jumps within a file, which may well be used substantially in a big file like the main tutorial. We need to think through the implications of this for the structuring of the tutorial. Possible add a link back to the "index" at the top of the file after each section? link added.