Menu
▾
▴
Re: [Repast-developer] aspectj and movement
|
From: Nick C. <nic...@ve...> - 2002-01-09 14:24:04
|
Hi all, Re. our current direction on spaces, movement and aspects. Well, I think the original idea and Tom should correct me here because he's doing the actual prototyping while I do all the useless jabbering, derives from the following chain of thought (mostly provoked by Gulya's thoughts on spaces). 1. Many models have agents that move about some sort of space. 2. The agent moving code for these space is fairly similar. 3. Given 1 and 2, agent movement seems like a good candidate for abstraction. 4. So, let's make a moveable agent base class that users can extend. 5. However, this seems wrong-headed as agent movement is a "role" or "aspect" rather than a core agent behavior. By core here I mean the behavior that is the point of the agent model. Movement is a means to or part of this behavior. Given Java's lack of multiple inheritance, a moveable agent base class seems to make agent heirarchies more difficult to code. For example, suppose I want to have agents that know how to play a cooperation type game and move around looking for other agents to play with. I can either use the moveable agent as my base class, or repast GameAgent as my base class, not both. Of course, I can compose one out of the other and forward the appropriate method calls, but this is what I mean by more difficult to code. This is an ease of use issue for the amateur programmer (i.e. the average repast soc. sci. user). 6. So, let's make a moveable agent interface. 7. This makes no sense either as we have no client code that expects agents to implement such an interface, and thus why make user's implement such an interface. Moreover, the whole point here is that we should provide the implementation for the users. 8. So, let's keep the interface, but have an aspect inject the implementation. In this case, the interface is not for client code interaction, but rather to mark the class, and let the user know what methods are available. My current thoughts about all this. I'm not sure how much better this is than the current situation. And as Tom has pointed out in his posts, the non-standard space library seems to be getting in the way here. Perhaps we should focus our efforts on reforming the space library for repast 2.0? Nick On Tue, 2002-01-08 at 18:33, Laszlo Gulyas wrote: > Hi, > > Well, I am not sure I completely understand what you are aimed at now, > nor I think I made myself clear enough. (My own ideas aren't necessarily > clear enough either.) This is because I actually have two 'scenarios' in > my mind, which I consider as short and longer term goals. So, let me > clarify these scenarios first, before getting back to your question. > > [Personal struggle with ideas begins] > > I) > The short term goal would be to have the space lib. 'standardized' > in a modular way, that I would baptise 'interchangeable spaces'. > This would allow the modeler, given that she follows some reasonable > coding guidelines (patterns), to use the same agent-model framework > for different spaces. (I would not expect this to work for all the possible > spaces, but for as much of them, as possible.) > > Maybe, all of this becomes clearer if you have a look at the attached > code, which is one of the 'test models' I am developing for the hexagonal > space lib. (Note, that it is still work in progress.) Ultimately, it will > set up > a space based on the parameters set by the user, will populate it by > agents that do some basic behavior and which, if probed, paint their > neighbors to a given color. > > As you can see, it's fairly straightforward to do this right now, but some > smoothening up of the general interfaces would make things much clearer > and easier. [As an ultimate application of all this, think of an 'evolver-like' > tool, in which you could select the space type from a pull-down menu...] > > Naturally, this will work as long as we have a general interface for spaces. > For 2D spaces, it is almost straightforward. It may also be possible for > general 'grid-like' spaces, too (e.g., 3D, 1D -- BTW as a byproduct of one of > my models, I have a Ring, ie. 1D Torus space as well). What I cannot see > yet is how to incorporate networks, too. (Maybe, what you have in your > aspect points to this direction...) > > II) > The longer term goal (well, maybe, dream) would be to free us from > the _thinking_ in terms of data structures representing spatial structures > (unless the space actually _has_ some behavior). > > Say, my agents have 3 variables: a, b and c. To implement my model, > I need to implement the behavior of them and display them somehow. > Where we usually handle spaces is: > > 1- to get references to other agents (resources) that are 'near', > in order to calculate the new values for a, b, and c; > 2- to store (some mapping of) the new a, b, and c values in it, and > 3- to create the display. > > In an ideal world, these would be handled in the following way: > > 1- I would call a method (of the model/environment/space after all?), > which takes an expression (say, describing agents whose value of > a is less than 2 units away from my a-value) and return references > to the objects described by the expression. > 2- No need for it (theoretically, at least). > 3- The display would basically be a mapping which goes over all > the agents and plots them according to their, say, a and c values. > (At least, it is this easy for grid-displays. I don't know > where this > would lead to in a more general case.) > > Later, if I decide to change the underlying 'space representation', it could > mean two things. I either want to display something else -- then I'd need to > change the mapping under 3. Or I want to change the expression in 1. > If I move from 2D to 3D, it simply means adding a new variable, plus changing > the expression in 1. (And probably, changing the display mapping, but not > necessarily.) > > So, it must be clear from now, that this is really off the ground stuff. > But still, > if it's possible, it might be useful, since it would require the modeler to > think > in terms of model variables and expressions, instead of computational > artefacts. > > [Personal struggle ends] > > Sorry, if I have repeated myself or if this ended up being boring. > Where all this points back to your question is the following. > > I don't know what of the goals above your approach is > closer to, but my guess is that to that of under I). You can see, > in that case, I am not afraid of referring to spaces at all. > It would be nice, however, to have a look at the methods you > have in the aspect. (I know it's well too premature.) > > On the other hand, if it's about something like the wild dreams > described under ii) then I am not sure I really understand how > your aspect will work. (My original vague thought about using > aspects was something along the lines of capturing all access > to certain variables /say, x and y/ in the agents' code and > using that to maintain a space object.) > > I have the feeling that your work aims at something different > from both of the scenarios I described above. Probably it's > something much more realistic than those. So, if you don't > mind, I'd look forward to a short explanation of your approach. > > Well, in retrospect, I am not sure this was useful as an > answer to the original question... :-) > > Gulya > > > At 10:09 AM 1/8/02 -0500, Nick Collier wrote: > >Anybody have any ideas on how to hide the reference to the space? Tom > >and I have been over this several times, but I'm keen to see what others > >think? > > > >Nick > > > >On Tue, 2002-01-08 at 10:00, th...@sr... wrote: > > > Yes, MoveableAgent is only a marker interface in a manner of speaking. > > > That is, from the point of view of the user no code need be implemented. > > > Now, as I have it written, the interface does have declarations. > > > This could easily be changed. However, I did this in order to document > > the > > > operations that would be available to the agent. If they weren't in the > > > interface they would only be listed in the aspect and I fear that would be > > > really confusing. I guess that is my primary concern: That the user > > > understand what's available from MoveableAgent, but not have to worry > > about > > > the implementation. > > > > > > As for the (general) architecture (And I emphasize, general), the > > > interface Moveable agent contains methods called move and several > > overloaded > > > getNeighbor functions. All of these methods take a reference to the space > > > object as a parameter. This is kind of a pain because we don't really > > have a > > > root space element, so I've separated it into Discrete2D and everyting > > else. > > > Point being that the agent passes a reference to Object which then has > > to be > > > casted in the aspect. Oh well. In order to use this, the user needs > > declare > > > that the agent implements MoveableAgent. Then, through the magic of > > aop, these > > > methods are available for use. This is a very loose description. > > > > > > Unfortunately, I think that it will be impossible for the agent to have no > > > reference to it's space (Sorry Gulya :) ). > > > > > > -Tom > > > > > > > > > On Tue, Jan 08, 2002 at 08:53:39AM -0500, Nick Collier wrote: > > > > I'm a bit confused. Is MoveableAgent a marker interface? And if it > > > > isn't, why not? That is, what sort of client code requires agents to be > > > > MoveableAgents? I'm not asking this to be annoying, but rather to get a > > > > sense of the big picture. (I know we've talked about this, but it would > > > > be good to have something documented). Can you sketch the architecture > > > > (perhaps too grand a notion here for a prototyping experiment), and walk > > > > through the steps that a user has to do to get a MoveableAgent and what > > > > they can do with it once they've got it. > > > > > > > > thanks, > > > > > > > > Nick > > > > > > > > > > > > > > > > On Mon, 2002-01-07 at 17:37, Laszlo Gulyas wrote: > > > > > Hi, > > > > > > > > > > This is just off the top of my head, but I don't think having a > > > > > flag- or identity interface should confuse the user. (As a > > > > > matter of fact, they might get much more confused by > > > > > aspects in general, but as I said before, I'd take the challenge.) > > > > > > > > > > In fact, repast already has identity interfaces (e.g. Torus > > > > > in the space lib), but it might well be true that a user > > > > > has never had to use them up to this point. > > > > > > > > > > Just my two cents. > > > > > > > > > > Gulya > > > > > > > > > > PS: I began to think that I should submit all my dreams > > > > > to this list, given the response time by which, e.g. this > > > > > independent-of-space dream of mine seems to be getting > > > > > into shape... ;-) > > > > > > > > > > At 10:59 AM 1/7/02 -0600, Thomas Howe wrote: > > > > > >Hi, > > > > > >I am currently working on implement movement behaviour using aspect > > > > > >oriented programming, so that the agent doesn't have to make calls > > > > > >directly to the space. We have discussed this a little on this > > list, and > > > > > >I'm just checking the feasibility. > > > > > > > > > > > >Here's where I stand. I am using aspectj as my aop language I > > have an > > > > > >"introduction aspect" as aspectj calls it, that adds a move method > > to the > > > > > >class. Basically, an introduction aspect adds new code to an > > existing > > > > > >class. This way the user never has to see the code, and we don't > > have > > > > > >issues of multiple inheritence. That's all fine and > > dandy. Here's the > > > > > >question. In order to use this, the aspect has to be able to > > determine > > > > > >which classes should have the added behaviour. The best way that > > I can > > > > > >think of to implement this is with interfaces. For example, a > > class would > > > > > >declare that it implements MoveableAgent and then the aspect adds > > the code > > > > > >as appropriate. I wonder, though, if this may be a problem. From > > the > > > > > >point of view of a user, when you declare that you implement an > > interface, > > > > > >you always have to implement the methods yourself. Will it be too > > > > > >confusing to declare that you implement an interface without actually > > > > > >writing any code? > > > > > > > > > > > >This was not the clearest note I've written, but I hope my point is > > > > > >somewhat understandable. Please let me know if it is not. > > > > > > > > > > > >Thanks, > > > > > >Tom > > > > > > > > > > > >_______________________________________________ > > > > > >Repast-developer mailing list > > > > > >Rep...@li... > > > > > >https://lists.sourceforge.net/lists/listinfo/repast-developer > > > > > > > > > > -- > > > > > Laszlo Gulyas, MSc Phone: (617) > > > > > 384-9216 > > > > > Government Department Weatherhead Center for International Affairs > > > > > Harvard University 602C Coolidge Hall > > > > > 1737 Cambridge street Cambridge, MA-02138 > > > > > > > > > > > > > > > _______________________________________________ > > > > > Repast-developer mailing list > > > > > Rep...@li... > > > > > https://lists.sourceforge.net/lists/listinfo/repast-developer > > > > -- > > > > Nick Collier > > > > Social Science Research Computing > > > > University of Chicago > > > > http://repast.sourceforge.net > > > > > > > > > > > > > > > > _______________________________________________ > > > > Repast-developer mailing list > > > > Rep...@li... > > > > https://lists.sourceforge.net/lists/listinfo/repast-developer > > > > > > -- > > > Tom Howe > > > Software Developer > > > SRC > > > University of Chicago > > > 773-834-3382 > >-- > >Nick Collier > >Social Science Research Computing > >University of Chicago > >http://repast.sourceforge.net > > > > > > > >_______________________________________________ > >Repast-developer mailing list > >Rep...@li... > >https://lists.sourceforge.net/lists/listinfo/repast-developer > > -- > Laszlo Gulyas, MSc Phone: (617) > 384-9216 > Government Department Weatherhead Center for International Affairs > Harvard University 602C Coolidge Hall > 1737 Cambridge street Cambridge, MA-02138 -- Nick Collier Social Science Research Computing University of Chicago http://repast.sourceforge.net |
