<DIV>Hope this is readable--I've got to get my edit window preferences straightened up :-)</DIV>
<DIV><BR><B><I>Ned Konz <ned@bike-nomad.com></I></B> wrote:</DIV>
<BLOCKQUOTE class=replbq style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 2px solid">
<P>On Sunday 16 November 2003 8:25 pm, mwgrant2001 wrote:<BR><BR>Ned: I don't understand why you need to do assignments.</P>
<P>mwg: The quick answer is because it suits the way I think about the problem. I did this a number of years ago as a text-based app. in LISP and so it makes a nice substantive exercise in Squeak. The keys to the (OO) LISP implementation were 1.) symbolic computation--in particular the ability of have objects create objects-- 2.) recursion, 3) and of it was object-oriented. Indeed the ease of the task was in part because I was able to think of the nodes as little agents which could determine from the context of their own creation where they belonged and what they had to do--when to create more nodes and when evaluate themselves and disappear into the garbage collector.</P>
<P>In more detail: The goal is to generate a decision tree (ala SRI approach), or rather have a decision tree generate and evaluate itself where only 'blueprints' of the uncertainty and decision nodes are input by the user via the on-the-fly construction of the influence diagram. Once the IF is specificied a base node--typically decision--is created and told to 'bloom'. By 'bloom'ing it then creates creates a node--typically an uncertainty--for each of it branch. </P>
<P>Each of these nodes will then in turn 'bloom' and so on until terminal nodes are reached. Here bloom cause the node to return a probability weighted value to that node which created it. When a node has values returned from each of the nodes it created, then it takes those values and uses them to calculate a weighted value which is returned to its creator, and so on.</P>
<P>So the tree, specified by the user on-the-fly, is generated and evaluated. </P>
<P>ned:<BR>Can't you just do something like:<BR><BR>myMorph _ Node named: answer asSymbol.<BR><BR>where the #named: message is setting state in the Node?</P>
<P>mwg: I don't know. That is why I asked for help in the first place. I appreciate the tip. One possible problem here is I don't know beforehand how many Morphs will be created and how many need to exist concurrently. So anything static like myMorph is not workable. I am looking for the ST equivalent of LISP's GENSYMing a string into an interned symbol in a dynamic context. (I believe this is the appropriate description--it's been years!!!). </P>
<P>BTW ultimately nodes would not be subclasses of a Morphic class, but each node instance would have one or more morphs as a variables. I just simplified things here. </P>
<P>ned:</P>
<P>More generally, look at the bigger picture: as you create these things, <BR>something's got to hold onto them or they won't continue to exist. </P>
<P>mwg: I expected scope could be part of the issue. I looked at some of other #evaluate's in th eimage but no examples or guidance...that was the determining factor for my the original email.<BR></P>
<P>Ned:<BR>So the assignment of <BR>c := TextMorph new<BR><BR>just doesn't make any sense here.</P>
<P>mwg:</P>
<P>It obviously didn't make sense to Squeak either :o). </P>
<P>But the need to do what I tried to do is critical to the present approach. So maybe the approach gets modified--but first I want to duplicate as much as possible. One of the reasons I started THIS EXERCISE is to see how much extra effort it is to do symbolic calculation in ST. I suspected and still suspect thatit is easier to do in LISP, but that isn't an issue. I'm PLAYING with ST.<BR></P>
<P>Ned:<BR>Going a bit further, if you look at the various flavors of #evaluate: you will <BR>find some where you can specify a context in which to do the evaluation. For <BR>instance, Workspaces hold variable bindings, and will provide them when and <BR>if the Compiler needs them (see #bindingOf:).<BR></P>
<P>mwg:</P>
<P>In truth I did. I thought scope was important and was not real surprised when the code didn't work. Obviously things like '#evaluate in:' showed up in the method finder, but no example and hence I could only that execution of 'Compiler evaluate' might take note of the 'scope' and act according. This is where even an example in the image would have been very helpful, but I can't be suprised there wasn't one. After all who would be looking at #evaluates unless the knew what they were doing, huh? <BR><BR>Thanks for you comments, Ned...they do give me some things to try.</P>
<P>Best Regards,</P>
<P>Mike</P>
<P> </P></BLOCKQUOTE><p><hr SIZE=1>
Do you Yahoo!?<br>
<a href="http://antispam.yahoo.com/whatsnewfree">Protect your identity with Yahoo! Mail AddressGuard</a>