Home » Archived » AMP » Building Agents in the GUI(Discussion on how to use the hierarchical GUI tree to build agent logic)
| Building Agents in the GUI [message #523043] |
Wed, 24 March 2010 20:45  |
John T. Murphy
Messages: 15
Registered: November 2009 |
Junior Member |
|
|
I'd like to open a discussion on how to build agent logic using AMP's hierarchical editor. As a starting point, consider:
This is the tree from the 'Movement' act of an Individual in the 'Epidemic' demo metaabm file. Here is the way the corresponding source code looks when this is generated as an Escape model:
public void movement() {
double movementDraw = getRandom().nextDouble();
if ((getStatus() != StatusEnum.dead
&& movementDraw < getEpidemic().getMovementProbability()
&& getStatus() != StatusEnum.symptomInfectious && movementDraw < getEpidemic()
.getMovementProbability())) {
{
Location neighboringLocation = (Location) ((org.ascape.model.space.Discrete) getEpidemic()
.getCity().getSpace())
.findRandomAvailableNeighbor(((org.ascape.model.CellOccupant) this)
.getHostCell());
if (neighboringLocation != null) {
if (getHostScape() != neighboringLocation.getScape()) {
die();
neighboringLocation.getEpidemic().getIndividualScape()
.add(this);
}
moveTo(neighboringLocation);
}
}
}
}
I'd like this forum to be a discussion about how AMP goes from the tree structure to the code.
As a starting point, consider the following question: notice that the code starts with a set of validation comparisons that define whether the agent should move or not; the criteria are: the agent is not status = dead; the agent is not status = symptomInfection; and the randomly selected value 'random draw' is less than the model attribute 'Movement Probability.' However, notice that the generated code compares the random value with the movement probability twice. Of course, comparing it twice doesn't matter (technically the short-circuit calculation will execute the comparison only once if it is false, and if it is true the first time then it will be true the second time). But still- out of a curiosity for how these things are structured, as an exercise, how would this double-comparison be eliminated?
Could we get a line-by-line (node by node) discussion of what, exactly, is going on in this little section of code and how it would be created? (By 'how' I mean what would be added as the first node, then the second, etc.- I notice, for example, that some nodes appear in the tree in multiple places, which I know corresponds to nodes that have multiple sources, AKA places where the data flow has branched and is coming back together, but I don't know how to edit this or what the code would look like for each elaboration from scratch to the finished code.) I'm also interested in how some parts (like the check to make sure the destination location is not null, and the reference to 'die()') got in the code at all; is there a template being applied, and if so where can I find it?
|
|
|
| Re: Building Agents in the GUI [message #523064 is a reply to message #523043] |
Wed, 24 March 2010 22:52  |
 Miles Parker
Messages: 1341
Registered: July 2009 |
Senior Member |
|
|
Hi John,
Great questions. See below..
| John T. Murphy wrote on Wed, 24 March 2010 16:45 | I'd like to open a discussion on how to build agent logic using AMP's hierarchical editor. As a starting point, consider:
As a starting point, consider the following question: notice that the code starts with a set of validation comparisons that define whether the agent should move or not; the criteria are: the agent is not status = dead; the agent is not status = symptomInfection; and the randomly selected value 'random draw' is less than the model attribute 'Movement Probability.' However, notice that the generated code compares the random value with the movement probability twice. Of course, comparing it twice doesn't matter (technically the short-circuit calculation will execute the comparison only once if it is false, and if it is true the first time then it will be true the second time). But still- out of a curiosity for how these things are structured, as an exercise, how would this double-comparison be eliminated?
|
We could optimize the template design further. In this case, we've got a somewhat atypical design -- usually the model designer would collapse all of ANY conditions to one level. In this case for explanatory or historical reasons (I can't remember which  ) I hadn't. If you look at the actual tree, to a naive implementor this looks like:
(A & B) & (A & C)
Now, we're not that naive and we could pretty easily take queries and reduce them. This is no different from what say a compiler designer would do with an optimizing compiler. As you say, it's a short circuit operation, so there isn't a performance penalty. But it looks silly and it would be nice to fix. The complex twist here is that the code might not always be this simple and so we have to balance simplicity in the template design (can we follow it and see that the logic works) with simplicity in the generated code. As time goes on, we'll refine the generated code -- the ideal is definitely to get it to what a good Java developer would come up with. We're not there, but we're pretty close in a lot of places, particularly where it counts IMHO. That part has to do with usages of the API idioms.
But the important thing is to get it right before we get it perfect. Part of that is we need to get some really good unit regression tests for generation going -- that will make me a lot more comfortable with playing around with optimizing things.
| Quote: | Could we get a line-by-line (node by node) discussion of what, exactly, is going on in this little section of code and how it would be created? (By 'how' I mean what would be added as the first node, then the second, etc.- I notice, for example, that some nodes appear in the tree in multiple places, which I know corresponds to nodes that have multiple sources, AKA places where the data flow has branched and is coming back together, but I don't know how to edit this or what the code would look like for each elaboration from scratch to the finished code.) I'm also interested in how some parts (like the check to make sure the destination location is not null, and the reference to 'die()') got in the code at all; is there a template being applied, and if so where can I find it?
|
So what this is is an almost anthropological exercise. In the case of the Ascape API, I wrote it so I have an idea of what I have in mind and what the most efficient usage is. In the case of Repast, I'm not as deep into it, so I might miss some efficiencies. That's where community comes in. If someone sees something and say's "that's kind of dumb -- if you did this it would be faster" then we can collect that knowledge and improve the templates. But the point is then that one programmer's in depth knowledge of a usage pattern is now transferred to all users.
One of the issues as I've pointed out before is that the tree editor makes it a bit difficult to scane what is going on with the program flow since all of the branches explode out. So for a graph with relations like:
a -> b -> c -> d
b - > e -> d
Looks like this:
i.e. d appears twice. That get's more annoying the larger the tree. I've designed better editors for this:
http://www.youtube.com/watch?v=lYp7Pq44CNM&feature=playe r_embedded
This will be in some non-OS analysis tools but I'll try to get a light-weight version out for the AMP editors as well.
OK, so here are some of the templates. Why don't you take a look and let me know if you see areas that we can gt into more detail on. Waring in advance, they're pretty dense, but the basic logic is actually pretty easy to understand once you get to thinking in that way:
Here's the basic Java:
http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.amp/org .eclipse.amp.amf/plugins/org.eclipse.amp.amf.gen/src/metaabm /tmpl/Java.xpt?root=Modeling_Project&view=markup
http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.amp/org .eclipse.amp.amf/plugins/org.eclipse.amp.amf.gen/src/metaabm /tmpl/infer.ext?root=Modeling_Project&view=markup
And here's where you can see the "die" method..
http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.amp/org .eclipse.amp.amf/plugins/org.eclipse.amp.amf.gen.ascape/src/ metaabm/ascape/tmpl/ScapeAspect.xpt?root=Modeling_Project&am p;view=markup
There is a lot more to explore in there..
|
|
| |
| Re: Building Agents in the GUI [message #523079 is a reply to message #523067] |
Thu, 25 March 2010 00:13 |
John T. Murphy
Messages: 15
Registered: November 2009 |
Junior Member |
|
|
Miles,
Thanks- this will help a lot. The locations of the templates seems to be a gold mine; I'll have to spend some time tunneling into it to see if I strike it as rich as I think, but it looks like exactly what I've been looking for. I have been browsing the CVS repository for a while trying to find it, but never could- there are just too many packages and subpackages and I didn't know where to look, nor what kind of file (.xpt) would contain the templates.
I'll have to mull over your comments about optimizing the templates; for now I'm more concerned about getting the basic knowledge about how to use the different kinds of nodes on the tree. For example, when you say 'we could pretty easily take queries and reduce them', I have to gulp and confess that it's not easy for me. Maybe I'm just trying to do things in a backwards way. I'll try to play around some more with the new info from the templates. I'll post more of my findings in this thread as I go.
I agree that it's very unfortunate that the tree display obscures some of the structure; I'd seen at least one screencast with your alternate GUI and am hoping to get my hands on it someday, but it's not in the version I have. Perhaps I'm idiosyncratic, but in some ways the xml, with a little bit of prettification, is actually easier for me to (or at least understand) than the GUI in its current state.
|
|
|
| Re: Building Agents in the GUI [message #523082 is a reply to message #523079] |
Thu, 25 March 2010 00:18 |
Miles Parker
Messages: 1341
Registered: July 2009 |
Senior Member |
|
|
| John T. Murphy wrote on Wed, 24 March 2010 20:13 | For example, when you say 'we could pretty easily take queries and reduce them', I have to gulp and confess that it's not easy for me.
|
By "we" I mean the generic "we", i.e. "somebody else".
| Quote: | I agree that it's very unfortunate that the tree display obscures some of the structure; I'd seen at least one screencast with your alternate GUI and am hoping to get my hands on it someday, but it's not in the version I have. Perhaps I'm idiosyncratic, but in some ways the xml, with a little bit of prettification, is actually easier for me to (or at least understand) than the GUI in its current state.
|
Yikes...given the amount of time I've spent on them, that's a bit discouraging. But I agree that a text representation an sometimes be better. I've been working on a text language for some time, but I've been waiting on getting these other things done to release it. The bottom line is that the default EMF editor is great for some things, but not so great for others. When you have to edit a lot of information it can be tedious to go back and forth from the tree view to the properties view and so on.
|
|
| | | | |
| Re: Building Agents in the GUI [message #523345 is a reply to message #523335] |
Fri, 26 March 2010 01:59 |
John T. Murphy
Messages: 15
Registered: November 2009 |
Junior Member |
|
|
Miles,
I've nearly completed the revised version of the Movement rule, that 'corrects' the order in which the initial validation is done so that the two 'status' elements are checked first and then the 'random draw' occurs. ('Corrects' is in quotes because I know it really doesn't matter- it's just a useful exercise!)
There is one spot of trouble. Toward the end as I'm reconstructing the actual movement, I get to the following point:
SELECT: New Location
QUERY: Available
QUERY: Neighbor
This is intended to match the original. The next step should be to create an 'Intersection' query that has 'Available' and 'Neighbor' as its sources (and will have the 'move' action as its target).
The problem occurs when I try to add the 'Intersection' as a target to 'Available'. My thinking, from the other places in the tree, is that I add the 'Intersection' query to 'Available' and then drag it so that it is a target of 'Neighbor' as well. When I first create it as a target of 'Available', it should say that it is a query of "Available & (?)" or something like that; when I drag it to 'Neighbor' it figures out that it is 'Available & Neighbor'.
But that's not what's happening: when I create the intersection query under 'Available', it responds by saying that the query is for 'New Location & Available'- that is, it looks up the hierarchy. I haven't tried edited the XML directly yet, but no other approach allows me to change this once it has made its choice.
Any thoughts? What am I doing wrong? I can send the file if you think that would help. Also, when I go to the original version of the Movement method and delete the original 'Intersection' query and try to rebuild it, it does the same thing.
Best, and thanks,
John
[Updated on: Fri, 26 March 2010 02:00] Report message to a moderator |
|
| | | | |
| Re: Building Agents in the GUI [message #523573 is a reply to message #523550] |
Fri, 26 March 2010 21:51 |
John T. Murphy
Messages: 15
Registered: November 2009 |
Junior Member |
|
|
Hi Miles,
| Miles Parker wrote on Fri, 26 March 2010 12:18 |
Yes, as I hope is mentioned in the docs somewhere, you need to select the node to link, then hold down the ctrl key and then drop the link on the node that you want to be the (shared) parent. This is the editor link behavior.
|
This doesn't work for me. I am certain there were times yesterday when I could drag and drop without ctrl, but as I've been working with it this afternoon the ctrl key doesn't do it, and no dragging and dropping works at all.
Incidentally, I was also often getting instances where the editor would be out of sync with the actual tree- for example, two nodes in the displayed tree that I knew to actually be the same node would have different labels, one of them the original default label and the other the new label that I had just modified. On a related note, I often have to change the default ID values because if I don't I get errors in the Error Log saying the values have to be alphanumeric; I can track this further and replicate if that would help.
| Quote: | There is another way to do this that you might find clearer though it takes more steps. In the properties view, click on the "upside down triangle" the options for the view. Then find the targets item, click on the (...) button, find the target and add it there.
|
This is very, very nice  ; I apologize for not noticing it before, but I can use it to do everything I need.
| Quote: | This is convincing me that I need to get the graph support into the base AMF editors as well.
|
I'm not quite sure what you mean by this, but remember, I may be an atypically dense user!
Back to my latest problem, which I still haven't resolved. All I am trying to do, of course, is replicate the end of the original tree. In pseudo-tree representation (it's hard to post pictures to this forum; I can if you need it) it's:
Selection: Neighboring Location
Query: Available Locations
Intersection: Available and Neighboring Locations
Move: Move to the 'Selection'
Query: Neighboring Locations
Intersection: Available and Neighboring Locations
Move: Move to the 'Selection'
Using the 'Advanced Properties' I can, I think, create all of these, and they look right in the tree. But here's the code this generates (NOTE: This code is from a different example, where I was playing with only this section, not any of the 'upstream' elements, except for one status check.)
public void secondMovement() {
if (getStatus() != StatusEnum.dead) {
{
org.ascape.util.Conditional nALocCondition = new org.ascape.util.Conditional() {
private static final long serialVersionUID = 6846144446402098985L;
public boolean meetsCondition(Object nALocCell) {
nALocCell = ((org.ascape.model.HostCell) nALocCell)
.getOccupant();
if (nALocCell instanceof Individual) {
return true;
} else {
return false;
}
}
};
Individual nALoc = null;
org.ascape.model.space.Location nALocLocation = ((org.ascape.model.space.Discrete) getEpidemic()
.getCity().getSpace()).findRandomAvailableNeighbor(
((org.ascape.model.CellOccupant) this).getHostCell(),
nALocCondition);
if (nALocLocation != null) {
nALoc = (Individual) ((org.ascape.model.HostCell) nALocLocation)
.getOccupant();
}
if (nALoc != null) {
if (getHostScape() != nALoc.getScape()) {
die();
nALoc.getEpidemic().getIndividualScape().add(this);
}
moveTo(((org.ascape.model.CellOccupant) nALoc)
.getHostCell());
}
}
}
}
On the plus side, there is some magic: the 'findRandomAvailableNeighbor' method is called, which, I assume, means that the 'intersection' is in the right place and AMP is working its behind-the-scenes magic to realize that if I'm selecting 'available' and 'neighbor' spaces and then finding the ones they have in common then it can achieve this in Escape by calling this single method. This is helping me understand what you were talking about with 'optimizing': the person making these trees should be able to let the framework generate some very cleverly optimized code.
But as you can see something is very amiss in my example. The original Epidemic model's movement rule doesn't have this 'conditional' stuff, and the 'findRandomAvailableNeighbor' method is being created with incorrect arguments (it won't compile).
This example also reminds me that I don't really know what a 'Select' node is and how that differs from the property that most (all?) nodes have of 'Root Selection'...
Thoughts? Thanks!
|
|
|
| Re: Building Agents in the GUI [message #523583 is a reply to message #523573] |
Fri, 26 March 2010 23:08 |
Miles Parker
Messages: 1341
Registered: July 2009 |
Senior Member |
|
|
| John T. Murphy wrote on Fri, 26 March 2010 17:51 | Hi Miles,
| Miles Parker wrote on Fri, 26 March 2010 12:18 |
Yes, as I hope is mentioned in the docs somewhere, you need to select the node to link, then hold down the ctrl key and then drop the link on the node that you want to be the (shared) parent. This is the editor link behavior.
|
This doesn't work for me. I am certain there were times yesterday when I could drag and drop without ctrl, but as I've been working with it this afternoon the ctrl key doesn't do it, and no dragging and dropping works at all.
|
I wonder if there is something up with the model. If you right click on it and select "Validate" do you get any errors? There are three things that can happen with drag and drop:
1. (No keys) Move the node.
2. (Option) Copy the node.
3. (Ctrl) Add a link to the node from another location.
Note that the interface will prevent you from doing something that isn't legal. And the cursor icon should change if you are trying to do something that is legal. i.e. for an option drag, you should get a "+" icon, or whatever it is on Windows. I'm not on Windows so I can't easily test this behavior but the last time I checked in windows it was working properly. An important note -- since ctrl-click maps to right click on most platforms, you need to do the mouse click first and then hold down the ctrl key -- otherwise it will be interpreted as a right-mouse click.
| Quote: | Incidentally, I was also often getting instances where the editor would be out of sync with the actual tree- for example, two nodes in the displayed tree that I knew to actually be the same node would have different labels, one of them the original default label and the other the new label that I had just modified. On a related note, I often have to change the default ID values because if I don't I get errors in the Error Log saying the values have to be alphanumeric; I can track this further and replicate if that would help.
|
Those are both bugs. Can you file them along with how you got there? Include the model as well, please.
| Quote: | | Quote: | There is another way to do this that you might find clearer though it takes more steps. In the properties view, click on the "upside down triangle" the options for the view. Then find the targets item, click on the (...) button, find the target and add it there.
|
This is very, very nice ; I apologize for not noticing it before, but I can use it to do everything I need.
|
OK, maybe I should document this and put it in the default list of property items.
| Quote: | | Quote: | This is convincing me that I need to get the graph support into the base AMF editors as well.
|
I'm not quite sure what you mean by this, but remember, I may be an atypically dense user!
|
These are the editors that allow you to design the model as a full graph so you don't see nodes appearing in more than one place.
| Quote: | Back to my latest problem, which I still haven't resolved. All I am trying to do, of course, is replicate the end of the original tree...
|
Basically, what we are trying to get to is the point where it is impossible to get an error in the Java code out of a model that doesn't report an error. That is an ideal, but we'd like to isolate any cases where that doesn't happen. Could you file a bug under AMF with the model that produces the bad code attached? I'll try to see what's going on there.
| Quote: | On the plus side, there is some magic: the 'findRandomAvailableNeighbor' method is called, which, I assume, means that the 'intersection' is in the right place and AMP is working its behind-the-scenes magic to realize that if I'm selecting 'available' and 'neighbor' spaces and then finding the ones they have in common then it can achieve this in Escape by calling this single method. This is helping me understand what you were talking about with 'optimizing': the person making these trees should be able to let the framework generate some very cleverly optimized code.
|
Yeah, that's exactly right. This is the kind of thing that a high-level representation affords. For example, if you know that you are moving to a place that is a neighbor and has some conditions attached, in Java API world, you could have a set of generic queries defined, but that might mean that the framework will search through every agent to find wether it meets the criteria, and *then* find out if they are neighbors! That seems like an extreme example but I've seen that happen in some frameworks and it's actually not at all trivial to try to optimize from a framework point of view. And then the API becomes almost too general to be usable. The alternative is to have a rich API like Ascape, but then it becomes an issue of putting together the high level methods that work for a specific case.
| Quote: | This example also reminds me that I don't really know what a 'Select' node is and how that differs from the property that most (all?) nodes have of 'Root Selection'...
|
So a root node is just a special case of a select node. Selects specify:
Agent: What we are looking for (for root, that's the owning agent)
Space: Where. This could be unspecified, which just means for all agents, and that's what we do in root, as we're executing roots against all agents.
Then all Actions *including Selects* have selections that they are acting from. So a Select that is referring to another select will find a selection from each member of the prior selection *based on where that select is in the query definition*.
Its easier to explain graphically.
|
|
|
| Re: Building Agents in the GUI [message #523594 is a reply to message #523583] |
Sat, 27 March 2010 04:36 |
John T. Murphy
Messages: 15
Registered: November 2009 |
Junior Member |
|
|
| Miles Parker wrote on Fri, 26 March 2010 16:08 |
I wonder if there is something up with the model. If you right click on it and select "Validate" do you get any errors?
|
The model validates successfully. I have to report, alas, that 'right clicking' didn't ever bring up a 'Validate' option on a context menu- I tried right clicking on the root node in the editor window and on the project and on the .metaabm file in the project, but no luck. However, 'Validate' was one of the options in the 'MetaABM' menu when the root node was selected in the editor window.
| Quote: |
There are three things that can happen with drag and drop:
1. (No keys) Move the node.
2. (Option) Copy the node.
3. (Ctrl) Add a link to the node from another location.
Note that the interface will prevent you from doing something that isn't legal. And the cursor icon should change if you are trying to do something that is legal. i.e. for an option drag, you should get a "+" icon, or whatever it is on Windows. I'm not on Windows so I can't easily test this behavior but the last time I checked in windows it was working properly. An important note -- since ctrl-click maps to right click on most platforms, you need to do the mouse click first and then hold down the ctrl key -- otherwise it will be interpreted as a right-mouse click.
|
I'll play with these tomorrow and confirm what happens on Windows with all variations; I'll create some tree structure that seems to play nice and use it.
| Quote: |
| Quote: | Incidentally, I was also often getting instances where the editor would be out of sync with the actual tree- for example, two nodes in the displayed tree that I knew to actually be the same node would have different labels, one of them the original default label and the other the new label that I had just modified. On a related note, I often have to change the default ID values because if I don't I get errors in the Error Log saying the values have to be alphanumeric; I can track this further and replicate if that would help.
|
Those are both bugs. Can you file them along with how you got there? Include the model as well, please.
|
Will do...
| Quote: |
| Quote: | | Quote: | There is another way to do this that you might find clearer though it takes more steps. In the properties view, click on the "upside down triangle" the options for the view. Then find the targets item, click on the (...) button, find the target and add it there.
|
This is very, very nice ; I apologize for not noticing it before, but I can use it to do everything I need.
|
OK, maybe I should document this and put it in the default list of property items.
| Quote: | | Quote: | This is convincing me that I need to get the graph support into the base AMF editors as well.
|
I'm not quite sure what you mean by this, but remember, I may be an atypically dense user!
|
These are the editors that allow you to design the model as a full graph so you don't see nodes appearing in more than one place.
| Quote: | Back to my latest problem, which I still haven't resolved. All I am trying to do, of course, is replicate the end of the original tree...
|
Basically, what we are trying to get to is the point where it is impossible to get an error in the Java code out of a model that doesn't report an error. That is an ideal, but we'd like to isolate any cases where that doesn't happen. Could you file a bug under AMF with the model that produces the bad code attached? I'll try to see what's going on there.
|
Again, will do...
| Quote: |
| Quote: | On the plus side, there is some magic: the 'findRandomAvailableNeighbor' method is called, which, I assume, means that the 'intersection' is in the right place and AMP is working its behind-the-scenes magic to realize that if I'm selecting 'available' and 'neighbor' spaces and then finding the ones they have in common then it can achieve this in Escape by calling this single method. This is helping me understand what you were talking about with 'optimizing': the person making these trees should be able to let the framework generate some very cleverly optimized code.
|
Yeah, that's exactly right. This is the kind of thing that a high-level representation affords. For example, if you know that you are moving to a place that is a neighbor and has some conditions attached, in Java API world, you could have a set of generic queries defined, but that might mean that the framework will search through every agent to find wether it meets the criteria, and *then* find out if they are neighbors! That seems like an extreme example but I've seen that happen in some frameworks and it's actually not at all trivial to try to optimize from a framework point of view. And then the API becomes almost too general to be usable. The alternative is to have a rich API like Ascape, but then it becomes an issue of putting together the high level methods that work for a specific case.
|
Cool- very much the same problems happen in the database world with query optimization. It occurs to me that there is a way to define a theory of what operations can happen without regard to order, so that any set of them nested can be re-ordered by the engine if necessary. You've probably thought about that in the implementation of the 'intersection' and 'union' nodes. One thing did occur to me: I found it odd that the movement was to a randomly selected location, but I didn't tell it to choose randomly- I might have been asking for a list of all the available, neighboring locations (to, say, put something on all of them). But this might be there and I'll find it when I'm more familiar and proficient.
| Quote: |
| Quote: | This example also reminds me that I don't really know what a 'Select' node is and how that differs from the property that most (all?) nodes have of 'Root Selection'...
|
So a root node is just a special case of a select node. Selects specify:
Agent: What we are looking for (for root, that's the owning agent)
Space: Where. This could be unspecified, which just means for all agents, and that's what we do in root, as we're executing roots against all agents.
Then all Actions *including Selects* have selections that they are acting from. So a Select that is referring to another select will find a selection from each member of the prior selection *based on where that select is in the query definition*.
Its easier to explain graphically.
|
I'll read this when I'm a bit more awake tomorrow (I know it's only 9:30 here, but I'm really a morning person!).
Thanks!
[Updated on: Sat, 27 March 2010 04:37] Report message to a moderator |
|
|
| Re: Building Agents in the GUI [message #523595 is a reply to message #523594] |
Sat, 27 March 2010 04:47 |
Miles Parker
Messages: 1341
Registered: July 2009 |
Senior Member |
|
|
| John T. Murphy wrote on Sat, 27 March 2010 00:36 |
Cool- very much the same problems happen in the database world with query optimization. It occurs to me that there is a way to define a theory of what operations can happen without regard to order, so that any set of them nested can be re-ordered by the engine if necessary.
|
Yes, exactly. In fact, a major inspiration for this whole approach and the decision is the success of declarative flavor query languages, e.g. SQL. A lot of folks don't realize this but people were doing very sophisticated query optimization -- including what amounts to dynamic code generation! -- in the late 70s. This is why one of the mottos for the design for me has been "underspecify".
| Quote: | One thing did occur to me: I found it odd that the movement was to a randomly selected location, but I didn't tell it to choose randomly- I might have been asking for a list of all the available, neighboring locations (to, say, put something on all of them).
|
That's quite deliberate. The assumption is always that you will want random behavior. Initially I had considered putting in a "random" query function or select attribute but I decided against it as randomness is a basic assumption of systems. One could relax this of course at generation time if one wanted. The engine (again) can determine when random execution isn't necessary. But there is an important distinction between say "play every one of my neighbors" and "play one of my neighbors". The former is not supported yet -- its actually quite simple to do on the code generation side but I've been puzzling through the best way to deal with it representationally. I think I've settled on making it a query term -- that seems to be the general way things are going. I'm on hold on all of those changes until we can get the basic AMF release golden.
|
|
|
| Re: Building Agents in the GUI [message #523597 is a reply to message #523595] |
Sat, 27 March 2010 05:23 |
John T. Murphy
Messages: 15
Registered: November 2009 |
Junior Member |
|
|
| Miles Parker wrote on Fri, 26 March 2010 21:47 | | John T. Murphy wrote on Sat, 27 March 2010 00:36 |
Cool- very much the same problems happen in the database world with query optimization. It occurs to me that there is a way to define a theory of what operations can happen without regard to order, so that any set of them nested can be re-ordered by the engine if necessary.
|
Yes, exactly. In fact, a major inspiration for this whole approach and the decision is the success of declarative flavor query languages, e.g. SQL. A lot of folks don't realize this but people were doing very sophisticated query optimization -- including what amounts to dynamic code generation! -- in the late 70s. This is why one of the mottos for the design for me has been "underspecify".
| Quote: | One thing did occur to me: I found it odd that the movement was to a randomly selected location, but I didn't tell it to choose randomly- I might have been asking for a list of all the available, neighboring locations (to, say, put something on all of them).
|
That's quite deliberate. The assumption is always that you will want random behavior. Initially I had considered putting in a "random" query function or select attribute but I decided against it as randomness is a basic assumption of systems. One could relax this of course at generation time if one wanted. The engine (again) can determine when random execution isn't necessary. But there is an important distinction between say "play every one of my neighbors" and "play one of my neighbors". The former is not supported yet -- its actually quite simple to do on the code generation side but I've been puzzling through the best way to deal with it representationally. I think I've settled on making it a query term -- that seems to be the general way things are going. I'm on hold on all of those changes until we can get the basic AMF release golden.
|
This is where things get really interesting for me, too- which is why I'm hoping to get up to speed with the basics, so that I can understand what you're doing with the more advanced issues. Thanks for helping as I bumble along! I'll keep posting documentation of everything that I find challenging, to help others join the fun, too.
Back at it tomorrow- best,
John
|
|
| | |
| Re: Building Agents in the GUI [message #525437 is a reply to message #524159] |
Tue, 06 April 2010 15:04 |
John T. Murphy
Messages: 15
Registered: November 2009 |
Junior Member |
|
|
In the first post of this forum thread I proposed two things: first, a line-by-line discussion of the original
example tree, and, second, a discussion of how the example tree could be modified to eliminate
the 'double-comparison' that occurs in the generated Escape code. Here are both of these.
First, here is the original tree:
For reference, here is the tree represented textually, so that labels can be added for reference:
A: Individual
B: Acts
C: Movement
D: Movement Draw
E: Movement Draw Lesser Probability Query
F: Movement Draw
G: Movement Probability
H: Status Different Dead Query
I: Status
J: Dead
K: Movement (Status Different Dead Query & Status Different Infectious Symptom Query)
L: Status Different Symptom Infectious Query
M: Status
N: Symptom Infectious
O: Movement (Status Different Dead Query & Status Different Infectious Symptom Query)
P: Neighboring Location
Q: Available
R: Neighboring Location: Available Neighboring
S: Move: Movement to Neighboring Location
T: Neighbor
U: Neighboring Location: Available Neighboring
V: Move: Movement to Neighboring Location
Before beginning, take note of line 'K'; line 'K' is actually the same as line 'O'; the difference is
that line 'O' is expanded, while line 'K' is not. I should be clearer here: 'the same' doesn't just mean
that the two lines have the same words in them; they are actually separate representations of the
same node, just displayed twice on the screen. This is an artifact of the fact that the tree is
hierarchical, but the node structure can include nodes that have more than one source (see the discussion
in some of the posts above this one). If line 'K' were expanded, it would show lines P-V twice.
Notice further than lines R and S are equivalent to lines U and V; if K were expanded, there would
then be four copies of these lines, instead of just two.
And for easy reference, here is the original code:
public void movement() {
double movementDraw = getRandom().nextDouble();
if ((getStatus() != StatusEnum.dead
&& movementDraw < getEpidemic().getMovementProbability()
&& getStatus() != StatusEnum.symptomInfectious && movementDraw < getEpidemic()
.getMovementProbability())) {
{
Location neighboringLocation = (Location) ((org.ascape.model.space.Discrete) getEpidemic()
.getCity().getSpace())
.findRandomAvailableNeighbor(((org.ascape.model.CellOccupant) this)
.getHostCell());
if (neighboringLocation != null) {
if (getHostScape() != neighboringLocation.getScape()) {
die();
neighboringLocation.getEpidemic().getIndividualScape()
.add(this);
}
moveTo(neighboringLocation);
}
}
}
}
With that in mind, here is the 'line-by-line' discussion:
Line 'A' is the 'Individual' node; not shown is the fact that this is a child of the 'Epidemic' node,
which is the root node for the entire model definition. Discussion of the possible child nodes
of models is beyond the scope of this post (but could be useful; does it exist somewhere?). Note that
'Individual' is a name that has been assigned for this model specifically. Throughout the course
of this discussion it will be useful to note what names are given to things and what are assigned
by default. Most names of things can be modified, but they can (whether automatic or not) be
used to understand what the node is doing.
The child node shown here for 'Individual' is 'Acts'. Individuals have other child nodes,
including Attributes and Styles, but these are not discussed here. All three names are used by
default (and I note that the 'ID' and 'Label' properties for 'Acts' is not 'Acts'; presumably there
is some specific structure that is being applied here that defines 'Acts' specifically?).
The first node shown here is 'Movement'. This is the name of an action that will be taken; the name
is assigned, not a default. One could imagine that there could be several kinds of movement that
are named differently and do different things, but here our Individuals only have one kind of movement,
so the name 'Movement' says it all. This name becomes the name of the method in the Escape code. The
kind of node that this is is 'Rule'; that is, when this node was added, the user selected the 'Acts'
node and selected 'Create Member'. The possible members of an 'Acts' node are: Schedule, Rule,
Build, Initialize, and Watch. Presumably these all do different things, but 'Rule' means that the
agent gets a method created with this name, and this method is then presumably called automatically
as the agent executes. (I know that Ascape allows 'rules' to be turned on and off, and that this can
be done independently if an agent has multiple rules; I also believe that Ascape allows rules to be executed
either by all agents going one by one and executing all their rules, or all agents executing rule 1 followed
by all agents executing rule 2; how does AMP handle this or allow it to be specified?) The icon next
to the name indicates that this is a 'Rule.' and not 'Build', 'Initialize', etc.
The next line (line 'D') is 'Movement Draw'. This is an Evaluate node: this means that when the
user added this node he clicked 'Movement' and selected 'Create Target...Evaluate'. The icon next to the
node indicates not the kind of target that it is but the content of that target. The 'Evaluate'
node acts as an assignment. In this case it assigns a variable- named 'movementDraw' to the value
that is returned (evaluated) by a random function. The function is called a 'Random Unit' and
draws a value from 0 to 1 with uniform distribution. It is the 'random' function that determines
the icon; there are other kinds of functions that can be used in an 'evaluate' node, and these result in
other icons. (It seems that the same icons are used to indicate 'random' whether the 'random' function
is used in an 'evaluate' or a 'query', right?)
Line 'E' is 'Movement Draw Lesser Probability'. This is a 'Query'. Queries have functions; this one's
is 'Logical Operator: Less than'. As should be obvious, this is a comparison (note the icon), and therefore requires
two operands; hence lines 'F' and 'G' are inputs to this 'Query'. One of them is the 'Movement Draw'
node, while the other is the 'Movement Probability' attribute of the model. The effect, of course, is
that the agent will move with a given probability. What's useful here is to note that even though
line 'E' is a "target" of line 'D', that means only that it is 'downstream' of it in execution;
line 'D' is not automatically an input to line 'E'. What line 'E' actually does is best considered in
light of the next two downstream elements.
Line 'E' has two targets- that is, the data flow takes two branches here. The first listed here is
line 'H'. This is 'Status Different Dead Query'. This is another query exactly parallel to line E, except
that its operator is not 'less than' it is 'different' (the icon is '!'). In this case the two inputs
are 'Status' and 'Dead'. 'Dead' is one of a set of enumerated permissible status values that an Individual
can have for its 'Status' attribute.
The other target from line 'E' is line 'L'. This is an identical 'Query' to line 'H', except that Status
is being compared to 'Symptom Infectious' and not 'Dead'. 'Symptom Infectious' is another of the
enumerated statuses that an Individual can have.
Note that there is some work going on here under the scenes: the code invokes 'getStatus', a method
of the Individual, to retrieve the value needed. Also, when this kind of node is being created,
once 'Status' is selected as the first input, the comparands available in the GUI drop-down
are drawn from the enumerated value list.
The two branches of data flow rejoin at line 'O' (which is also line 'K'; because it is a target of both
line 'H' and line 'L', it appears downstream of both of them). This is an 'Intersection' node; it
executes a logical 'AND'; the icon is the logical symbol for 'AND'. (The parallel node for 'OR' is a
'Union' node.) Unlike the functions used in the above Query nodes, this node acts on its upstream
sources- not just the immediate sources, but their sources, etc. (Presumably this stops somewhere- at
a 'Select'?).
The result of the 'Intersection' node is an 'if' statement that has as its conditional the collection
of upstream sources, all joined by 'AND' conjunctions. Incidentally, this is (probably... Miles?) why
the 'Movement Draw' comparison is done twice: The first test is the first source (Status != Dead),
and then its upstream source, 'Movement Draw Lesser', is the second; the third is the second source
(Status != Symptom Infectious), followed by its source , which is 'Movement Draw Lesser' again.
The next line is line P, and this marks a departure from the preceding data flow. It defines a 'Select'
node. Selects are something like root nodes. In this example, the 'Individual/Act/Movement' structure
defines an effective 'root node' that means that this 'Rule' will be run 'upon' each agent during the
simulation run; references in the initial parts of the structure, i.e. to 'status' referred to the
agent performing the action. Here the 'Select' node redefines the point of reference: what is being
selected is a 'Location'.
The structure here is what is key: "Select" is followed by some set of queries; this is then followed
by a 'Command'. The Command, in this case, is line S (which is also line 'V'). The Select itself
specifies the kind of agent being selected ('Location' [Note: In later versions of the Epidemic model
this is called 'Place'] and the space in which it will be sought. The two queries are on lines
Q and T: an 'Available' query, which seeks Locations that are unoccupied, and a 'Neighbor' query,
which seeks neighbors of the Individual that is the root of the whole movement.
As targets of both of these queries there is (line R, aka line U) an Intersection operator. This
has the effect of finding the cells that are both 'Available' and 'Neighbors'.
The final target is the 'Move' action itself (line S, aka line V), which carries out the action of
moving the agent to the destination.
There is, however, a lot of behind-the-scenes work that is done before arriving at the Escape code for
this. The code is:
{
Location neighboringLocation = (Location) ((org.ascape.model.space.Discrete) getEpidemic()
.getCity().getSpace())
.findRandomAvailableNeighbor(((org.ascape.model.CellOccupant) this)
.getHostCell());
if (neighboringLocation != null) {
if (getHostScape() != neighboringLocation.getScape()) {
die();
neighboringLocation.getEpidemic().getIndividualScape()
.add(this);
}
moveTo(neighboringLocation);
}
}
Notice all the work that has been done:
The queries are folded into a single function call, 'findRandomAvailableNeighbor()'. Note
that if there are multiple possible destinations (more than one available neighbor cell)
one is selected randomly.
The result of this is checked for null- perhaps there is no available cell among the neighbor cells.
There is an additional check to determine whether the agent is moving 'across' scapes (Miles?).
One important aspect of this last section can be usefully pointed out. AMP is deliberately without a specific
syntax, but it follows a pattern: Select, Query, Command. The latter part of this example
follows that pattern nicely.
Also in an earlier post I posed a puzzle: how to eliminate the double-evaluation of the
'Movement Draw'. Here is one solution:
Notice that not all the labels are as pretty as in the above, but the analogous labels should be clear.
This version starts with two queries that are both immediate children of the Act's root node.
These are the status queries; both of them are sources to an 'Intersection' query, which then has
a single target, the 'Movement Draw' construction. Downstream of this the structure is identical
to the above 'movement' structure. The code that is generated in Escape is:
public void movementRev1() {
if ((getStatus() != StatusEnum.dead && getStatus() != StatusEnum.symptomInfectious)) {
double movementDraw = getRandom().nextDouble();
if (movementDraw < getEpidemic().getMovementProbability()) {
{
Location neighboringLocation = (Location) ((org.ascape.model.space.Discrete) getEpidemic()
.getCity().getSpace())
.findRandomAvailableNeighbor(((org.ascape.model.CellOccupant) this)
.getHostCell());
if (neighboringLocation != null) {
if (getHostScape() != neighboringLocation.getScape()) {
die();
neighboringLocation.getEpidemic()
.getIndividualScape().add(this);
}
moveTo(neighboringLocation);
}
}
}
}
}
This, as promised, avoids the 'double' comparison issue in the above code.
At this point, however, we go back to Miles's first rebuttal to the whole exercise- mainly whether the
'double comparison' issue was important. Key to this is that we ought to be able to create a valid
and intelligible structure without worrying about how it will be implemented on a particular target.
So, we could imagine a 'better' code generator that would create code for Escape or another target
implementation platform where issues like this one would be resolved automatically and the most
efficient way of evaluating the total set of criteria would be found. (Note that
although conceptually the same, there is a difference between the two approaches: the
random number call is always done in the original, but only sometimes in the revision.)
|
|
|
| Re: Building Agents in the GUI [message #525552 is a reply to message #525437] |
Tue, 06 April 2010 21:11 |
Miles Parker
Messages: 1341
Registered: July 2009 |
Senior Member |
|
|
Hi John,
Thanks for the incredibly detailed analysis. I'm sorry that it seems that you have to reverse engineer things a bit.
A few general notes.
1. I think it is important not to get too caught up in the issue of where the nodes are appearing in the tree structure, though it is super helpful for users of the current incarnation. I'm going to go ahead and contribute some stuff that is part of the Investigator product so that users can see the DAG structure directly, but that is going to have to wait until Zest 2.0 gets contributed to Eclipse, which is dependent on them getting through a couple of more IP hurdles. (Too much inside baseball, probably..)
2. Likewise for the exact code generation itself, except as I say for when it creates an actual semantic difference. In that case, we should be interested / concerned. See below for more on that.
3. There are definitely things that I would have done differently had I been starting from scratch, and will do with the new version of Acore. So as always, suggestions about what aspects are not clear are most helpful.
So a few answers to the detailed items -- let me know if I missed anything important.
| John T. Murphy wrote on Tue, 06 April 2010 11:04 | All three names are used by
default (and I note that the 'ID' and 'Label' properties for 'Acts' is not 'Acts'; presumably there
is some specific structure that is being applied here that defines 'Acts' specifically?).
|
Yes, this is really just an accident of the structure of the underlying model and how it relates to the editor. These could really just be suppressed. Also, the node really should be called "Actions" -- (Acts was the original name) I'm fixing that just now.
| Quote: | The possible members of an 'Acts' node are: Schedule, Rule,
Build, Initialize, and Watch. Presumably these all do different things, but 'Rule' means that the
agent gets a method created with this name, and this method is then presumably called automatically
as the agent executes. (I know that Ascape allows 'rules' to be turned on and off, and that this can
be done independently if an agent has multiple rules; I also believe that Ascape allows rules to be executed
either by all agents going one by one and executing all their rules, or all agents executing rule 1 followed
by all agents executing rule 2; how does AMP handle this or allow it to be specified?
|
That's correct, one of the design features of Ascape / Escape is the ability to control a lot of this stuff at runtime. Both Ascape and AMF take the position of under-specifying this stuff so that while there is a default interpretation, that interpretation can be enriched at generation time (AMF) or runtime (Ascape). With other targets such as Repast, you'll have different constraints and capabilities.
A future (imagined for now) feature of AMF will be to actually support more explicitly this generation and runtime configuration information. You see a beginning of that with the parameterization support. You may not have seen this yet, but there is a facility for specifying input parameters for models. That could / will be extended to allow configuration of say which rules are executed for a given model run. But this is much more complex, as you will need a kind of xpath like support for navigating the tree and specifying rulesets within the containment hierarchy.
But this begins to get interesting and complex, because it ties into the Acore design itself. Acore will support agent fragments, and that will also provide a level of behavior tuning.
| Quote: | (It seems that the same icons are used to indicate 'random' whether the 'random' function
is used in an 'evaluate' or a 'query', right?)
|
Yes, that is true and we should improve that. As you've probably noted, we differentiate queries from evaluations by making queries blue and evaluations orange.
| Quote: | (The parallel node for 'OR' is a
'Union' node.) Unlike the functions used in the above Query nodes, this node acts on its upstream
sources- not just the immediate sources, but their sources, etc. (Presumably this stops somewhere- at
a 'Select'?).
|
No, at the point in which the Query tree stops. Any subsequent queries act as filters on that selection. This can be a bit of a complex issue, I'll provide more details of that in the documentation. And see additional remarks at bottom.
| Quote: | There is an additional check to determine whether the agent is moving 'across' scapes (Miles?).
|
Yes, exactly right! This is a case where the framework can get around issues with the underlying framework by using domain knowledge from the model. In this case, we know that we might actually be moving to another space entirely, not just moving within the scape. So we call "die" which despite its name in the context of Ascape simply means, "remove yourself from your containing scape". Again, in Ascape if we aren't contained by any scape, we aren't really part of the model anymore, and so are effectively dead. (The Ascape Leave method does something somewhat similar, but die works better for this case.)
| Quote: | (Note that
although conceptually the same, there is a difference between the two approaches: the
random number call is always done in the original, but only sometimes in the revision.)
|
Yes, this is a case where the model would be semantically identical though it would not reproduce the same result from the same set of seeds (supporting that in general probably doesn't make sense across targets).
Note that as you imply, a model developer should not have to concern her or himself with such issues. As you say, the generator developer is concerned with optimizing such things where necessary. This is important because one should remember that a model design can carry subtle information about intent. And though that intent might not matter in a particular case -- and there might be a more efficient way to express it -- there might be pedagogical or compositional reasons to do things in a particular way. For example, take the case above.
The simplest thing to do would be to just do an intersection of the whole thing. But that would be both difficult to scan intuitively, and it would lose generality. What I would like to be able to do is to specify a generic check for wether I move or not, and then define the actual move criteria separately.
Note that you cannot always simply mix and match the order, because of some subtleties in query mechanism. (BTW, I agree that the term "Query" is overloaded and confusing -- queries combine aspects of Query Statement terms and Queries, and I had originally considered referring to them as "Terms". TBD for Acore..) See (currently non-existing) query docs or the Acore design page for more on that.
cheers,
Miles
|
|
| |
| Re: Building Agents in the GUI [message #525575 is a reply to message #525556] |
Tue, 06 April 2010 22:35 |
John T. Murphy
Messages: 15
Registered: November 2009 |
Junior Member |
|
|
Yes, though I confess I lost track of it while worming through some of the details of this. When I stumbled back upon it this morning it did help me get back on track a bit. I found it a bit hard to absorb the first time, but I think it's easier to understand now that I worked through this exercise (that said, there are still parts that I guess I'll understand better after the next exercise!).
You mention a lot of things that pique my interest- agent fragments?- so, I'll keep plugging away and look forward to seeing (and being able to comprehend) more.
Best,
John
|
|
|
Goto Forum:
Current Time: Tue Apr 16 17:48:17 GMT 2024
Powered by FUDForum. Page generated in 2.95524 seconds |
] 
Search
Help
Register
Login
Home
. I've been able to create the kinds of structures I was unable to do yesterday, so I think I can move ahead now.