repast-developer

Re: [Repast-developer] new test

[Nick C. <nic...@ve...>]

Thanks! Tom is also going to be doing some tests. Can you coordinate
with him so that nobody does any extra work.

thanks!

Nick


On Tue, 2002-01-08 at 17:10, Laszlo Gulyas wrote:
> At 10:04 AM 1/8/02 -0500, Nick Collier wrote:
> >Hi,
> >
> >I've added a new test to our meager collection of tests
> >(uchicago/src/sim/test). Its called AllTest and it runs all the other
> >tests. So if you create any new unit tests, please add those tests to
> >AllTest. I've also updated the README appropriately.
> >
> >We need more tests for the space code (excluding MultiGrids) and the
> >other packages. These have been tested informally but it would be better
> >to have proper unit tests. Any volunteers?
> 
> Hi,
> 
> Perhaps, I am not the best one to make any more promises, so I will
> refrain from doing so. However, I will definitely make tests for the hexa
> library as it comes along. And those tests, in turn, are kind of tests for
> the other 2D stuff as well, since I am relying on code reuse pretty much.
> 
> Gulya
> 
> >Nick
> >
> >--
> >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

[Fwd: Re:[Repast-developer] aspectj and movement]

[Nick C. <nic...@ve...>]

I don't think Tom's post made it to the list.

Nick

-----Forwarded Message-----

> From: Thomas Howe <th...@sr...>
> To: nic...@ve...
> Subject: Re:[Repast-developer] aspectj and movement
> Date: 08 Jan 2002 10:05:35 -0600
> 
> Hi all,
> I seem to be still having problems getting emails from my machine to actually post to the list.
> 
> In anycase, Nick, I've been working on the problem of eliminating the spatial reference from the agent.  As I have written it, the only reference is in the constructor, and it is as an Object.  I handle all the casting in the aspect.  Basically, I introduce a method on the class called setWorld(Object world).  Beyond that, the code is completely free of any reference to the space.  I now have a method move(Point old, Point new) that handles the movement.  
> 
> this is the interface for MoveableAgent:
> 
> move(Point old, Point new)
> 
> Vector getNeighbors(Point loc, int xExtent, int yExtent);
> 
> Object getObjectAt(Point loc);
> 
> setWorld(Object world);
> 
> 
> There are more methods, mostly overloaded ones, that handle other things, and a few private methods,  but this should give an idea of what I mean by space independence.  One concern is specialty spaces like heatspace.  This space has methods like diffuse that we cannot account for in the aspect(of course, I can for heatspace, but generally I cannot).  This would still require either a reference to the space or to be handled in the model.  I think.  If anyone has any thoughts, that would be cool.
> 
> -Tom 

Re: [Repast-developer] aspectj and movement

[Laszlo G. <gu...@la...>]

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

Re: [Repast-developer] new test

[Laszlo G. <gu...@la...>]

At 10:04 AM 1/8/02 -0500, Nick Collier wrote:
>Hi,
>
>I've added a new test to our meager collection of tests
>(uchicago/src/sim/test). Its called AllTest and it runs all the other
>tests. So if you create any new unit tests, please add those tests to
>AllTest. I've also updated the README appropriately.
>
>We need more tests for the space code (excluding MultiGrids) and the
>other packages. These have been tested informally but it would be better
>to have proper unit tests. Any volunteers?

Hi,

Perhaps, I am not the best one to make any more promises, so I will
refrain from doing so. However, I will definitely make tests for the hexa
library as it comes along. And those tests, in turn, are kind of tests for
the other 2D stuff as well, since I am relying on code reuse pretty much.

Gulya

>Nick
>
>--
>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

Re: [Repast-developer] aspectj and movement

[Nick C. <nic...@ve...>]

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] new test

[Nick C. <nic...@ve...>]

Hi,

I've added a new test to our meager collection of tests
(uchicago/src/sim/test). Its called AllTest and it runs all the other
tests. So if you create any new unit tests, please add those tests to
AllTest. I've also updated the README appropriately. 

We need more tests for the space code (excluding MultiGrids) and the
other packages. These have been tested informally but it would be better
to have proper unit tests. Any volunteers?

Nick

-- 
Nick Collier 
Social Science Research Computing
University of Chicago 
http://repast.sourceforge.net

Re: [Repast-developer] aspectj and movement

[Nick C. <nic...@ve...>]

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

Re: [Repast-developer] aspectj and movement

[Laszlo G. <gu...@la...>]

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

RE: [Repast-developer] Question on New Scheduler

[North, M. <no...@an...>]

Gulya:

Insuring that simulation results are reproducible is
clearly an critical issue.  It should be noted that
guaranteeing reproducible results is a concern that
goes well beyond multi-threaded scheduling.  For
example, the introduction of random numbers into
simulations, as is commonly practiced with agent-based
modeling, requires careful attention to insure
reproducibility.  Furthermore, the implications of
reproducibility require thoughtful consideration since
most simulations that use random numbers are valid
only when run in a stochastic mode.  Individual runs
of such simulations may be useful for model debugging
but should not be used to draw scientific conclusions.

That being said, while multi-threaded scheduling in
Java is non-deterministic even within a single virtual
machine, multi-threaded programs still can be
deterministic.  It all depends on the way that the
programs are written.

The new multi-threaded scheduler is being developed
using the "Principle of Least Astonishment."  Thus,
by default, the scheduler will operate in a
deterministic, single-threaded mode.  This will
prevent breakage of existing programs and new
programmers alike.

Multi-threaded scheduling can be activated on a
case-by-case basis by specifying both a start time and
an end time for tasks.  The start time is the
simulation scheduling time you are already familiar
with in RePast.  The end time defines when the
results of a given task are available for other tasks.
These other tasks may be run on separate, concurrent
threads.  Details such as thread pooling and
concurrency control will be automatically handled by
the new scheduler.  Note that the end time is in the
same units as the start time, which is to say units
of simulation time, not wall clock or process time.

Given a set of valid concurrent tasks, a new task can
properly be started if the start time of the new task is
less than or equal to the minimum end time of all of
the currently running tasks.  This is true since the end
time states when the results of a given task are available
for other tasks to use.  The scheduler will use this
rule to select tasks to be run concurrently.  It is up
to model developers to properly specify end times if they
wish tasks to be concurrent.  The details of managing and
using this information will be embedded within the new
scheduler.  The new RePast scheduler will thus make
multi-threading available by simply adding optional
simulation clock end times to the standard scheduler
method calls.

Clearly, proper use of multi-threading will require
model developers to correctly set task end times.
Choosing to use this new feature will thus create a
new responsibility for developers.  However, which
powerful programming feature can be used carelessly
yet effectively?

Michael

-----Original Message-----
From: Laszlo Gulyas [mailto:gu...@la...]
Sent: Sunday, January 06, 2002 9:38 PM
To: rep...@li...
Subject: [Repast-developer] Question on New Scheduler


Hi Everybody and Happy New Year to All, 

I seem to be lagging back on all the issues here, and I am
sorry for that. 

My question here is about the new scheduling mechanism
in the works that has been announced some weeks ago. I
have to tell, it sounds terrific in general. What I am
worried about, however, is replicability of the simulation results,
when using multi-threaded scheduling. As far as I know,
but I might be wrong of course, the exact scheduling of
threads in Java is undeterministic (at least, accross
JVMs). Am I right on this? If yes, can we still somehow
guarantee that the simulation results will be reproducible? 

Well, that's it. Thanks for the answers in advance, and
I am sorry if this what I wrote makes no sense. 

Gulya
 --
Laszlo Gulyas          (617) 384-9216
Government Dept.       Weatherhead Center
602C Coolidge Hall     for International Affairs
1737 Cambridge str.    Cambridge, MA 02138

_______________________________________________
Repast-developer mailing list
Rep...@li...
https://lists.sourceforge.net/lists/listinfo/repast-developer

[Repast-developer] aspectj and movement

[Thomas H. <th...@sr...>]

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] Question on New Scheduler

[Laszlo G. <gu...@la...>]

Hi Everybody and Happy New Year to All, 

I seem to be lagging back on all the issues here, and I am
sorry for that. 

My question here is about the new scheduling mechanism
in the works that has been announced some weeks ago. I
have to tell, it sounds terrific in general. What I am
worried about, however, is replicability of the simulation results,
when using multi-threaded scheduling. As far as I know,
but I might be wrong of course, the exact scheduling of
threads in Java is undeterministic (at least, accross
JVMs). Am I right on this? If yes, can we still somehow
guarantee that the simulation results will be reproducible? 

Well, that's it. Thanks for the answers in advance, and
I am sorry if this what I wrote makes no sense. 

Gulya
 --
Laszlo Gulyas          (617) 384-9216
Government Dept.       Weatherhead Center
602C Coolidge Hall     for International Affairs
1737 Cambridge str.    Cambridge, MA 02138

[Repast-developer] RePast Scheduler Upgrade Goals

[North, M. <no...@an...>]

RePast Developers:

After a long series of discussions with Nick Collier and David Sallach, I
have decided to upgrade the RePast scheduling system.  My plan is to have a
new RePast scheduler ready for beta testing by the end of January 2002, and
have the new scheduler ready for final release by the end of February 2002.
As part of this process, Nick, David, and I have agreed to the following
goals:

1.) The new RePast scheduler should allow arbitrary time steps to be
specified by double precision numbers that can vary between events, instead
of the current fixed integer time steps.  This will clarify the design and
simplify the development of many models because it will allow the each
application's natural time intervals to be directly used.
2.) The new RePast scheduler should allow concurrent task execution.  This
will speed model execution on multiprocessor systems since several threads
of execution may be active simultaneously.
3.) The new RePast scheduler should be completely compatible with previous
versions.  This will allow all previously working models to continue to work
without modifications.

Nick, David, and I have developed a design based on these goals.  I will
forward more information this proposed design in the next few days.  Before
I do this, I am interested in finding out if people have any thoughts or
comments on these goals.

Mike

Michael J. North
Software Engineer
Argonne National Laboratory
Decision and Information Sciences Division
Complex Adaptive Systems Section

9700 S. Cass Avenue
Argonne, IL 60439

E-mail: no...@an...
Telephone: (630) 252-6234
Facsimile: (630) 252-6073

[Repast-developer] Re: Repast-developer digest, Vol 1 #37 - 1 msg

[<sky...@sa...>]

>From: Nick Collier <vze...@ve...>
>To: repast-developer <rep...@li...>
>Date: 17 Dec 2001 14:36:40 -0500
>Subject: [Repast-developer] network models
>
>Hi,
>
>I've re-written and added some code to the repast parts responsible for
>visualizing network models.

sounds great!  Did you look at the draft of John's banking model I coded
right at the end?  I remember doing something to hack the "standard" normal
inheritance system to make the "node" and "drawable node" the same. Not
saying it was useful, just that I did it!

Will this effect any of the network stats and visualisation stuff?  (i.e.
can they be fixed or speeded up so they won't have to do all the careful
casting?)

Also, (low priority) it is probably worth making similar changes to the
edges, so they can eventually be made dashed, have width, etc..

best,
 -skye

[Repast-developer] network models

[Nick C. <vze...@ve...>]

Hi,

I've re-written and added some code to the repast parts responsible for
visualizing network models. I'm writing because this changes the
canonical way to write such code. The old system was to wrap nodes in
drawable nodes such that all the network behavior was forward from the
drawable to the wrapped node. This worked okay for simple models, but
caused confusion in more complicated models and made it difficult for
nodes to change their shape. All this was precipitated by comments Skye
made last summer and more particularly trying to help a U. of C. student
with her model. 

The new code works in a similar way, wrapping the drawable in a node.
Drawable behavoir is forwarded from the node to the drawable. The
drawables are bit different here and it is much easier to swap them in
and out, changing the drawing behavior of the node. I've re-written
jiggle to reflect the changes - a bit less code, and much cleaner and
less confusing.

Note that this only changes the canonical way to write such models, the
old way still works fine as long as you can keep it straight.

I'm going to re-write Skye's JinGirModel so that it uses the new
mechanism and can be included as a demo in the next release as an
example of a real network model, something we've needed for a while now.


Nick

-- 
Nick Collier 
Social Science Research Computing
University of Chicago 
http://repast.sourceforge.net

Re: [Repast-developer] aspect oriented programming

[Nick C. <vze...@ve...>]

Ah, I seem to remember you saying something about aspects during your
MAML presentation at the SwarmFest in L.A.=20

I agree. The aspect stuff should be as nearly completely hidden as
possible.

Nick

On Sat, 2001-12-15 at 11:13, Laszlo Gulyas wrote:Hi,

I must be growing old or something. We used aspect oriented=20
programming of some sort in MAML a few years ago, and I was
quite excited about it. But for some reason, the thought has=20
never occured me to use it for the space issue, even though=20
I am still subscribed to the AspectJ mailing list.

(We used aspects for the separation of the model and the=20
observer in MAML. For details, see:=20

L=E1szl=F3 Guly=E1s, Tam=E1s Kozsik: =84The Use of Aspect Oriented Programm=
ing=20
in Scientific Simulations", Proceedings of the 6th Fenno-Ugric Symposium
on=20
Software Technology (FUSST'99), August 19-21, 1999 Estonia.=20
http://www.sztaki.hu/~gulyas/Papers/AOPSS.zip)

I think, this could be a very good approach to our problem with
spaces, but one that needs careful implementation. I mean, we should
keep it as transparent to end-users as we can. (They'd almost
certainly run away if we start talking about aspect before they
actually grabbed the concepts of object-orientation... ;-))

Just my 2 cents.

Gulya

At 09:49 AM 12/15/01 -0500, Nick Collier wrote:

    Hi,
   =20
    Tom told me ages ago that I should take a look at some aspect
    oriented
    programming material and I finally did. I've been reading the docs
    that
    come with aspectj (http://www.aspectj.org). It looks like AspectJ's
    "introduction" might be a way to add some the functionality we are
    looking for, particularly with respect to spaces.=20
   =20
    What I'm thinking here is that we want agents to know about their
    spaces
    and act within them without the modeler doing so explicitly. The
    point
    being that agent mobility and spatial relationships can be seen as a
    kind of role (thanks David!) that cuts across agent hierarchies. The
    hierarchy expresses some model specific behavior or at least the
    behavior that is the point of the model. Mobility and spatial
    relationship are a means to achieving this behavior. Gulya has
    written
    about this previously, better than I have here so see the archives
    for
    more.=20
   =20
    So, does any one have any experience with aspectj or aspect oriented
    programming? Is this a crazy idea? It does make compilation more
    complicated by we can easily solve this with a batch or shell file
    for
    compilation.
   =20
    Comments?
   =20
    Nick
   =20
    --=20
    Nick Collier=20
    Social Science Research Computing
    University of Chicago=20
    http://repast.sourceforge.net
   =20
   =20
   =20
    _______________________________________________
    Repast-developer mailing list
    Rep...@li...
    https://lists.sourceforge.net/lists/listinfo/repast-developer
--
Laszlo Gulyas, MSc              Phone: (617)
384-9216                          =20
Government Department   Weatherhead Center for International Affairs
Harvard University              602C Coolidge Hall             =20
1737 Cambridge street           Cambridge, MA-02138
--=20
Nick Collier=20
Social Science Research Computing
University of Chicago=20
http://repast.sourceforge.net

Re: [Repast-developer] aspect oriented programming

[Laszlo G. <gu...@la...>]

<html>
Hi,<br>
<br>
I must be growing old or something. We used aspect oriented <br>
programming of some sort in MAML a few years ago, and I was<br>
quite excited about it. But for some reason, the thought has <br>
never occured me to use it for the space issue, even though <br>
I am still subscribed to the AspectJ mailing list.<br>
<br>
(We used aspects for the separation of the model and the <br>
observer in MAML. For details, see: <br>
<br>
L=E1szl=F3 Guly=E1s, Tam=E1s Kozsik: =84The Use of Aspect Oriented Programmi=
ng
<br>
in Scientific Simulations&quot;, Proceedings of the
6<font size=3D1><sup>th</sup></font> Fenno-Ugric Symposium on <br>
Software Technology (FUSST'99), August 19-21, 1999 Estonia. <br>
<a href=3D"http://www.sztaki.hu/~gulyas/Papers/AOPSS.zip"=
 eudora=3D"autourl">http://www.sztaki.hu/~gulyas/Papers/AOPSS.zip</a>)<br>
<br>
I think, this could be a very good approach to our problem with<br>
spaces, but one that needs careful implementation. I mean, we=20
should<br>
keep it as transparent to end-users as we can. (They'd almost<br>
certainly run away if we start talking about aspect before they<br>
actually grabbed the concepts of object-orientation... ;-))<br>
<br>
Just my 2 cents.<br>
<br>
Gulya<br>
<br>
At 09:49 AM 12/15/01 -0500, Nick Collier wrote:<br>
<blockquote type=3Dcite class=3Dcite cite>Hi,<br>
<br>
Tom told me ages ago that I should take a look at some aspect
oriented<br>
programming material and I finally did. I've been reading the docs
that<br>
come with aspectj
(<a href=3D"http://www.aspectj.org/" eudora=3D"autourl">http://www.aspectj.o=
rg</a>).
It looks like AspectJ's<br>
&quot;introduction&quot; might be a way to add some the functionality we
are<br>
looking for, particularly with respect to spaces. <br>
<br>
What I'm thinking here is that we want agents to know about their
spaces<br>
and act within them without the modeler doing so explicitly. The
point<br>
being that agent mobility and spatial relationships can be seen as=20
a<br>
kind of role (thanks David!) that cuts across agent hierarchies.=20
The<br>
hierarchy expresses some model specific behavior or at least the<br>
behavior that is the point of the model. Mobility and spatial<br>
relationship are a means to achieving this behavior. Gulya has
written<br>
about this previously, better than I have here so see the archives
for<br>
more. <br>
<br>
So, does any one have any experience with aspectj or aspect=20
oriented<br>
programming? Is this a crazy idea? It does make compilation more<br>
complicated by we can easily solve this with a batch or shell file
for<br>
compilation.<br>
<br>
Comments?<br>
<br>
Nick<br>
<br>
-- <br>
Nick Collier <br>
Social Science Research Computing<br>
University of Chicago <br>
<a href=3D"http://repast.sourceforge.net/"=
 eudora=3D"autourl">http://repast.sourceforge.net</a><br>
<br>
<br>
<br>
_______________________________________________<br>
Repast-developer mailing list<br>
Rep...@li...<br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/repast-developer" eu=
dora=3D"autourl">https://lists.sourceforge.net/lists/listinfo/repast-develop=
er</a>
</blockquote>
<x-sigsep><p></x-sigsep>
--<br>
Laszlo Gulyas,=
 MSc<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Phone: (617)=
 384-9216<x-tab>&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-t=
ab><br>
Government Department <x-tab>&nbsp;&nbsp;</x-tab>Weatherhead Center for=
 International Affairs<br>
Harvard=
 University<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>602C Coolidge Hall=
 <x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><br>
1737 Cambridge=
 street<x-tab>&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;</x-tab>Cambridge, MA-02138</html>

[Repast-developer] aspect oriented programming

[Nick C. <vze...@ve...>]

Hi,

Tom told me ages ago that I should take a look at some aspect oriented
programming material and I finally did. I've been reading the docs that
come with aspectj (http://www.aspectj.org). It looks like AspectJ's
"introduction" might be a way to add some the functionality we are
looking for, particularly with respect to spaces. 

What I'm thinking here is that we want agents to know about their spaces
and act within them without the modeler doing so explicitly. The point
being that agent mobility and spatial relationships can be seen as a
kind of role (thanks David!) that cuts across agent hierarchies. The
hierarchy expresses some model specific behavior or at least the
behavior that is the point of the model. Mobility and spatial
relationship are a means to achieving this behavior. Gulya has written
about this previously, better than I have here so see the archives for
more. 

So, does any one have any experience with aspectj or aspect oriented
programming? Is this a crazy idea? It does make compilation more
complicated by we can easily solve this with a batch or shell file for
compilation.

Comments?

Nick

-- 
Nick Collier 
Social Science Research Computing
University of Chicago 
http://repast.sourceforge.net

[Repast-developer] life redux

[Nick C. <vze...@ve...>]

Hi,

I've made some more changes to the life model (there in CVS so you can
get them if you want). I'm posting this because the additions support an
"infinite" space. Its not exactly infinite but rather a 46339 x 46339
grid (21447302921 cells). This is built on a sparse matrix so the idea
is that agents have lots of room to roam, but that the number of agents
is extremely small vs. the number of cells. The display for this space
is a view into a particular sub-grid of the larger grid, a kind of
sliding window into the larger space. You can move this window with
arrow keys, although you need to make sure that the display frame (that
is the actual display window on your desktop) is selected. I think the
display threading is synchronized correctly so that you can slide the
window will the simulation is running. At least this works on Linux. 

The "infinite" space and display are not generalized beyond the the life
model and their implementations are in the life package. So, I bring
this up not just to bother y'all, but to point out that those of you
working on spaces may want to look at this code as an example of an
"infinite" space / display. 

Nick

-- 
Nick Collier 
Social Science Research Computing
University of Chicago 
http://repast.sourceforge.net

[Repast-developer] rscript removed

[Nick C. <vze...@ve...>]

Hi,

I just removed the rscript directory from CVS. A fresh compile from a
clean update should now compile.

Nick

-- 
Nick Collier 
Social Science Research Computing
University of Chicago 
http://repast.sourceforge.net

[Repast-developer] Conway's life and few other things

[Nick C. <vze...@ve...>]

Hi,

I wanted to add a demo model that used SimpleModel as a base class to
the RePast distribution. So, I implemented Conway's life. SimpleModel is
really suited for this as the same thing happens every tick and the
model divides up nicely into an "execution" and post-execution phase. 

The canonical implementation takes place on an "infinite" space, but I
used a torus. You still get gliders, guns, etc., but obviously the
longer term dynamics are different. If there's time, I'll do an
"infinite" space version, if only so I can muck up the space package a
bit more :). Its in CVS so feel free to update and take a look.

As part of implementing Life, I made some important changes to
ListPropertyDescriptor and the reflector package in general. For those
that don't know the reflector package handles probing, that is, the
display of an object's properties and the gui manipulation of them.
Previously, the gui widgets responsible for editing the properties
returned the edited value as String. This String was then transformed
appropriately and passed as the argument to some set method. This was
fine for primitives and Strings, but made it difficult to "edit"
objects. I changed the Widget interface to return an Object rather than
a String and added some new code to invoke the set method with an Object
argument. This impacts all areas of probing. I ran some tests, and
everything seems okay, but let me know if there are any problems.

The point of doing this was to allow named Objects in
ListPropertyDescriptors. In the case of Life, the Objects are setup
objects for initializing the grid. You chose the name of the initial
grid pattern and this sets the setup object. Then this SetUp object's
setup method gets called when the model is setup. (Whew! That's a lot of
setup).

Lastly, in making the evolver distribution last week, I moved some stuff
out of the rscript package. The result is that a fresh update and
compile from scratch from CVS won't work. I'll remove the rscript
directory tomorrow, and that should fix the problem.

Nick

-- 
Nick Collier 
Social Science Research Computing
University of Chicago 
http://repast.sourceforge.net

Re: [Repast-developer] Re: Repast-developer digest, Vol 1 #24 - 2 msgs

[Laszlo G. <gu...@la...>]

At 10:32 AM 12/2/01 -0500, Nick Collier wrote:
>On Fri, 2001-11-30 at 21:46, Laszlo Gulyas wrote:
>[...]



> > - I tend to like the use of ObjectLocation in the multi-occupation grids.
> >    Maybe, we should provide this functionality in all discrete grids.
> >    (I am lacking it when I want to implement moving -- it's OK that I can
> >     grab my neighbors, but it would also be nice if I could grab the
> > neighborous
> >     cells/locations, too.)
>
>I was hoping to do this soon after I wrote the multi-occupancy grid, but
>I never got around to it. Its still on the list, but feel free to do it
>yourself, if you have the time :).

OK, I'll feel, but these times I am not that rich timewise, either... :-)

> >
> > - Finally, in Node (in the networking library), it would be nice to have
> > something
> >    like getEdgeTo(Node), which would return the edge that connects the
> > actual node
> >    to the parameter (or null).
>
>I added a some new methods along this line to DefaultNode last thurs.
>and can certainly add this as well. However, these new methods recognize
>that a node may have multiple edges to or from another node. For
>example, a son may have a business link and a family link with his
>father. Internally there is now a HashMap with nodes as keys and a
>HashSet of edges as values. Given this, what would be better do you
>think --
>
>public Iterator getEdgesTo(Node node)
>
>or
>
>public HashSet getEdgesTo(Node node)

Good question. I have no preference right now, as I have no
concrete example in mind yet to match them to. So, I'd
probably go for the more general one, which is the latter.

Gulya

[...]

--
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

Re: [Repast-developer] Re: Repast-developer digest, Vol 1 #24 - 2 msgs

[Nick C. <vze...@ve...>]

On Fri, 2001-11-30 at 21:46, Laszlo Gulyas wrote:
> Hi,
> 
> I am not sure I completely understood everything in these mails below
> (I have little clue about GIS's), but they certainly sounded interesting.
> 
> Could you explain me at some length what a congruency matrix is?
> And I am ashamed to ask, but I am not sure I understand the centroid
> thing either... ;-)
> 
> Finally, how is geometry represented in standard gis software? I mean, maybe
> we could borrow something from there, too . I am fine with ArrayList, but 
> who knows...
> 
> On the other hand, I have a couple of less visionary 'proposals', too. All
> of these are just quick ideas, so feel free to point out the defects in them.
> 
> - I tend to like the use of ObjectLocation in the multi-occupation grids.
>    Maybe, we should provide this functionality in all discrete grids.
>    (I am lacking it when I want to implement moving -- it's OK that I can
>     grab my neighbors, but it would also be nice if I could grab the 
> neighborous
>     cells/locations, too.)

I was hoping to do this soon after I wrote the multi-occupancy grid, but
I never got around to it. Its still on the list, but feel free to do it
yourself, if you have the time :).

> 
> - Also, I would propose to introduce another standard functionality. Something
>    like DistanceFromTo()... This is because while calculating the distance 
> on normal
>    grids is fairly easy, it can get rather complicated in other cases. (The 
> hexagonal
>    lattice is one example, but I can also think of a subclass of the normal 
> 2DGrid,
>    which contains walls and other obstacles...)
> 
> - Finally, in Node (in the networking library), it would be nice to have 
> something
>    like getEdgeTo(Node), which would return the edge that connects the 
> actual node
>    to the parameter (or null).

I added a some new methods along this line to DefaultNode last thurs.
and can certainly add this as well. However, these new methods recognize
that a node may have multiple edges to or from another node. For
example, a son may have a business link and a family link with his
father. Internally there is now a HashMap with nodes as keys and a
HashSet of edges as values. Given this, what would be better do you
think --

public Iterator getEdgesTo(Node node)

or 

public HashSet getEdgesTo(Node node)


Nick


-- 
Nick Collier 
Social Science Research Computing
University of Chicago 
http://repast.sourceforge.net

Re: [Repast-developer] Re: Repast-developer digest, Vol 1 #28 - 5 msgs

[Laszlo G. <gu...@la...>]

Hi Again,

Please find my comments below.

At 05:38 PM 11/29/01 -0800, Skye Bender-deMoll wrote:

>[...]
>
>I'm not at all familiar with the gis architecture, but one thing to
>consider is how the space framework works with the network framework.  for
>ex, if each spaces is keeping track of its adjacent neighbors, or you have
>matrix for looking up neighbors, this is conceptualy identical to a
>network, with all associated benifits and problems.  (i.e. if you are using
>an adjacency matrix, mem requriments go up as the SQUARE of the number of
>cells!)

Sure. This is a very important point. In the long run, everything should
be integrate with the networking framework smoothly. What I would
expect is that at the top of the hierarchy we have some core functionality
that applies to all spaces. And then, at one point, there is a forking in
the tree and the grid-like stuff goes one way, the more general, networking
stuff the other.

>also, I wonder if it is worth trying to do a bit of look ahead for how the
>repast libraries are structred.  Will the the concepts under the 2d spaces
>still make sense when extened to 3d?

In my work, I try to make this sure. My real problem is the parameters.
Wherever you need to identify a location, you need to pass the coordinates.
And the number of arguments define the signature of the method...
But since, I don't have any solution to this and cannot foresee any easy
way around it either, I decided to live with it... :-)


>webstart stuff sounds damn cool.  unfortunatly I've got a bit of a
>bandwidth problem havn't looked at it.  be cool to bundle up the jinGirNew
>demo and tell the authors..

Yeah! I forgot in my last mail. That's really cool!
How much work did it take?


Gulya

>xo,
>  -skye

Re: [Repast-developer] Re: Repast-developer digest, Vol 1 #24 - 2 msgs

[Laszlo G. <gu...@la...>]

Hi,

I am not sure I completely understood everything in these mails below
(I have little clue about GIS's), but they certainly sounded interesting.

Could you explain me at some length what a congruency matrix is?
And I am ashamed to ask, but I am not sure I understand the centroid
thing either... ;-)

Finally, how is geometry represented in standard gis software? I mean, maybe
we could borrow something from there, too . I am fine with ArrayList, but 
who knows...

On the other hand, I have a couple of less visionary 'proposals', too. All
of these are just quick ideas, so feel free to point out the defects in them.

- I tend to like the use of ObjectLocation in the multi-occupation grids.
   Maybe, we should provide this functionality in all discrete grids.
   (I am lacking it when I want to implement moving -- it's OK that I can
    grab my neighbors, but it would also be nice if I could grab the 
neighborous
    cells/locations, too.)

- Also, I would propose to introduce another standard functionality. Something
   like DistanceFromTo()... This is because while calculating the distance 
on normal
   grids is fairly easy, it can get rather complicated in other cases. (The 
hexagonal
   lattice is one example, but I can also think of a subclass of the normal 
2DGrid,
   which contains walls and other obstacles...)

- Finally, in Node (in the networking library), it would be nice to have 
something
   like getEdgeTo(Node), which would return the edge that connects the 
actual node
   to the parameter (or null).

Well, that's for today.

Gulya

At 09:30 AM 11/28/01 -0600, you wrote:
>I guess that it is now my turn to add to the conversation.  For those of you
>who don't know, I am working on gis spaces.  Up to now, I've been using raster
>spaces whose nieghbors can be calculated just like grids.  Now that I'm 
>getting to work on the vector spaces this approach is not 
>appropriate.  From what I've read in this thread, I really like the idea 
>of using radius to determine nieghborhoods.  This is how we have 
>historically calculated this sort of thing in gis using the buffer.  the 
>other approach I've seen is to maintain a congruency matrix that can be 
>searched to find neighbors.  This might work for hexagonal spaces, but 
>becomes problematic in gis spaces (even though that's where I've seen it) 
>because of the non uniform nature of gis shapes.  I think that using the 
>centroid and a buffer (either oval or circle) to calculate neighbors is a 
>good way to approach the general space interface.  As Skye says, the grid 
>can use this functionality and add the moore, vn neighborhoods in the 
>subclass.  Lord knows it will make my task easier if I don't have to deal 
>with those concepts (I wouldn't even
>know where to begin).
>
>So, that's just what I'm thinking.
>

[and]

Ooops, one more thing. In gis, we generally think of buffers a circular 
radii (is that the right word? :)). As a matter of fact, all of the 
libraries I use and have seen (for gis) have a method called: buffer(double 
distance). Just something to think about. On the other hand, they also 
return a single object (a new geometry) instead of a collection, so I'm 
going to have to change that anyway. But nonetheless.
-Tom,
who continues rambling

[Repast-developer] Re: Repast-developer digest, Vol 1 #28 - 5 msgs

[<sky...@sa...>]

>Message: 4
>Date: Thu, 29 Nov 2001 11:13:14 -0600
>From: Thomas Howe <th...@sr...>
>To: rep...@li...
>Subject:  Re: [Repast-developer] 'Report'
>
>I guess that it is now my turn to add to the conversation.  For those of you
>who don't know, I am working on gis spaces.  Up to now, I've been using raster
>spaces whose nieghbors can be calculated just like grids.  Now that I'm getting
>to work on the vector spaces this approach is not appropriate.  From what I've
>read in this thread, I really like the idea of using radius to determine
>nieghborhoods.  This is how we have historically calculated this sort of thing
>in gis using the buffer.  the other approach I've seen is to maintain a
>congruency matrix that can be searched to find neighbors.  This might work for
>hexagonal spaces, but becomes problematic in gis spaces (even though that's
>where I've seen it) because of the non uniform nature of gis shapes.  I think
>that using the centroid and a buffer (either oval or circle) to calculate
>neighbors is a good way to approach the general space interface.  As Skye
>says,+the grid can use this functionality and add the moore, vn
>neighborhoods in the
>subclass.  Lord knows it will make my task easier if I don't have to deal with
>those concepts (I wouldn't even know where to begin).
>
>So, that's just what I'm thinking.
>
>-tom
>
>
>--__--__--
>
>Message: 5
>Date: Thu, 29 Nov 2001 11:16:01 -0600
>From: Thomas Howe <th...@sr...>
>To: rep...@li...
>Subject: [Repast-developer] (no subject)
>
>Ooops, one more thing.  In gis, we generally think of buffers a circular radii
>(is that the right word? :)).  As a matter of fact, all of the libraries I use
>and have seen (for gis) have a method called: buffer(double distance).  Just
>something to think about.  On the other hand, they also return a single object
>(a new geometry) instead of a collection, so I'm going to have to change that
>anyway.  But nonetheless.
>
>-Tom,
>who continues rambling
>
>P.S.  While I was frustrated with something else, I decided to try out the
>webstart stuff.  If anyone wants to see it in action, install webstart
>from the sun page, then go to http://stiltfire.src.uchicago.edu/test1.jnlp
>

I'm not at all familiar with the gis architecture, but one thing to
consider is how the space framework works with the network framework.  for
ex, if each spaces is keeping track of its adjacent neighbors, or you have
matrix for looking up neighbors, this is conceptualy identical to a
network, with all associated benifits and problems.  (i.e. if you are using
an adjacency matrix, mem requriments go up as the SQUARE of the number of
cells!)

also, I wonder if it is worth trying to do a bit of look ahead for how the
repast libraries are structred.  Will the the concepts under the 2d spaces
still make sense when extened to 3d?

webstart stuff sounds damn cool.  unfortunatly I've got a bit of a
bandwidth problem havn't looked at it.  be cool to bundle up the jinGirNew
demo and tell the authors..

xo,
 -skye