Menu
▾
▴
Re: [Repast-developer] aspectj and movement
|
From: Laszlo G. <gu...@la...> - 2002-01-08 23:29:11
|
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 |
