repast-developer

[Repast-developer] (no subject)

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

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

Re: [Repast-developer] 'Report'

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

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

[Repast-developer] test

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

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

Re: [Repast-developer] 'Report'

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

Good, I figured as much, but didn't want to be presumptuous. When the
code is ready can you check it into CVS or I can do it if you'd rather.

thanks,

Nick

On Wed, 2001-11-28 at 21:11, Laszlo Gulyas wrote:
> Sure. I think, it should be part of repast as it would be confusing
> having the different parts of the space library in different package
> hierarchies. I only put them in a new branch, because I wanted
> to save building the whole repast.jar all the time.
> 
> Gulya
> 
> At 08:40 AM 11/28/01 -0500, you wrote:
> >Wow, this is fantastic. I had forgotten about the whole web start thing,
> >I'm glad you brought it up. Can we distribute your hex classes either as
> >part of repast itself, or as part of a contrib type distribution?
> >
> >thanks,
> >
> >Nick
> 
> --
> 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

Re: [Repast-developer] 'Report'

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

Sure. I think, it should be part of repast as it would be confusing
having the different parts of the space library in different package
hierarchies. I only put them in a new branch, because I wanted
to save building the whole repast.jar all the time.

Gulya

At 08:40 AM 11/28/01 -0500, you wrote:
>Wow, this is fantastic. I had forgotten about the whole web start thing,
>I'm glad you brought it up. Can we distribute your hex classes either as
>part of repast itself, or as part of a contrib type distribution?
>
>thanks,
>
>Nick

--
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] 'Report'

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

Wow, this is fantastic. I had forgotten about the whole web start thing,
I'm glad you brought it up. Can we distribute your hex classes either as
part of repast itself, or as part of a contrib type distribution?

thanks,

Nick

On Tue, 2001-11-27 at 19:49, Laszlo Gulyas wrote:
> Hi Again,
> 
> Sending off my previous mail, I realized that I might as well
> give you some hints on what I was spending my spare time
> over here (w.r.t. Repast, that is). And as I've just recently put
> something like this together, below I will be unscrupulously
> doctoring that text to keep you all informed.
> 
> Gulya
> 
> >1) I have completed the 'methodology' of the 'appletization' of
> >     Repast models. It is a bit slow, but works -- and if you have
> >     a good (and well-configured) browser, it could be expected to
> >     cache the files.
> >     The bad news, however,  is that it does not seem to work on the Mac,
> >     or at least, I could not find out what browser you would need for that.
> >     (I.e. it would require some more reading.)
> >
> >      In general, what is missing is a complete README & HOWTO
> >      on this, but that should come soon -- although it has a very low
> >      priority now.
> >
> >2) As the files required for the applet are quite large, I've explored
> >     several ways to make them slim. None of them is completed,
> >     however.
> >
> >         a) The use of Sun's WebStart tool (JNLP API), instead of Applets.
> >             This is a very promising area: the JNLP API is basically a new
> >             approach to the programs-from-the-web idea, a competitor to
> >             applets, but supported by Sun, too. The idea is that you install
> >             a specific program on your computer (WebStart), which takes
> >             over the handling of the program from your browser. WebStart
> >             _does_ cache programs and what's more, is capable of 
> > automatically
> >             updating them, if they've changed on the web.
> >
> >             Problem: I could not find any reference on WebStart working on
> >             the Mac (although, it should as it's written in Java).
> >
> >             Actually, I don't have a running version of any Repast model for
> >             NT or unix either, as I did not have time to explore this 
> > path any
> >             further.
> >
> >             It has zero priority now.
> >
> >         b) Automatic 'repackaging' of the repast jar's, in order to 
> > include only
> >             the files that are actually used. I've played around with 
> > several
> >             free tools, and developed some testing code on my own, too.
> >             None of these seems to work right away, although they have
> >             different problems. The bottom line, however, is that it is not
> >             quite as easy to do this as it may seem, as a lot of repast's
> >             functionality is activated 'on-demand', i.e. if the user 
> > presses a
> >             button, etc.
> >
> >            Moreover, it turns out that Repast itself (i.e., the 
> > repast.jar) is NOT
> >            overwhelmingly big at all. What makes the downloading time too 
> > much
> >            is the additional .jar's coming with Repast. And repackaging 
> > those is
> >            even trickier. The final obstacle that stopped me was that some
> >            of them is actually digitally signed -- what is basically to 
> > prevent others
> >            (thus us) from tampering with the package.
> >
> >            I haven't worked on this for a couple of weeks now, and it has
> >           zero priority.
> >
> >3) I've been mostly working on the hexagonal space (sub)library.
> >I have the following (main) classes implemented:
> >
> >         - Object2DHexaGrid
> >         - Object2DHexaTorus
> >         - Object2DHexaDisplay
> >         - Value2DHexaDisplay
> >         - Diffuse2DHexa
> >
> >         for testing purposes:
> >
> >         - Hexabugs -- a hexagonal version of heatbugs
> >         - a hexagonal version of Schelling's Segregation model
> >         - SpaceTest -- a simple model to test spaces, displays, and more
> >           importantly, probes. It is also a good experiment as a framework
> >           that includes all possible spaces (except networks) and allows the
> >           user to dynamically select the appropriate one.
> >
> >Remaining tasks:
> >
> >         - Multi2DHexaGrid
> >         - Multi2DHexaTorus
> >         - Ordered2DHexaGrid
> >         - Ordered2DHexaTorus
> >         - Multi2DHexDisplay
> >         - NetworkHexaGridDisplay
> >
> >         for testing purposes:
> >
> >         - updating SpaceTest to include the multiple occupation spaces.
> >         - finalizing and completing the sporadic jUnit tests I have now.
> 
> 
> 
> _______________________________________________
> 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] 'Report'

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

Hi Again,

Sending off my previous mail, I realized that I might as well
give you some hints on what I was spending my spare time
over here (w.r.t. Repast, that is). And as I've just recently put
something like this together, below I will be unscrupulously
doctoring that text to keep you all informed.

Gulya

>1) I have completed the 'methodology' of the 'appletization' of
>     Repast models. It is a bit slow, but works -- and if you have
>     a good (and well-configured) browser, it could be expected to
>     cache the files.
>     The bad news, however,  is that it does not seem to work on the Mac,
>     or at least, I could not find out what browser you would need for that.
>     (I.e. it would require some more reading.)
>
>      In general, what is missing is a complete README & HOWTO
>      on this, but that should come soon -- although it has a very low
>      priority now.
>
>2) As the files required for the applet are quite large, I've explored
>     several ways to make them slim. None of them is completed,
>     however.
>
>         a) The use of Sun's WebStart tool (JNLP API), instead of Applets.
>             This is a very promising area: the JNLP API is basically a new
>             approach to the programs-from-the-web idea, a competitor to
>             applets, but supported by Sun, too. The idea is that you install
>             a specific program on your computer (WebStart), which takes
>             over the handling of the program from your browser. WebStart
>             _does_ cache programs and what's more, is capable of 
> automatically
>             updating them, if they've changed on the web.
>
>             Problem: I could not find any reference on WebStart working on
>             the Mac (although, it should as it's written in Java).
>
>             Actually, I don't have a running version of any Repast model for
>             NT or unix either, as I did not have time to explore this 
> path any
>             further.
>
>             It has zero priority now.
>
>         b) Automatic 'repackaging' of the repast jar's, in order to 
> include only
>             the files that are actually used. I've played around with 
> several
>             free tools, and developed some testing code on my own, too.
>             None of these seems to work right away, although they have
>             different problems. The bottom line, however, is that it is not
>             quite as easy to do this as it may seem, as a lot of repast's
>             functionality is activated 'on-demand', i.e. if the user 
> presses a
>             button, etc.
>
>            Moreover, it turns out that Repast itself (i.e., the 
> repast.jar) is NOT
>            overwhelmingly big at all. What makes the downloading time too 
> much
>            is the additional .jar's coming with Repast. And repackaging 
> those is
>            even trickier. The final obstacle that stopped me was that some
>            of them is actually digitally signed -- what is basically to 
> prevent others
>            (thus us) from tampering with the package.
>
>            I haven't worked on this for a couple of weeks now, and it has
>           zero priority.
>
>3) I've been mostly working on the hexagonal space (sub)library.
>I have the following (main) classes implemented:
>
>         - Object2DHexaGrid
>         - Object2DHexaTorus
>         - Object2DHexaDisplay
>         - Value2DHexaDisplay
>         - Diffuse2DHexa
>
>         for testing purposes:
>
>         - Hexabugs -- a hexagonal version of heatbugs
>         - a hexagonal version of Schelling's Segregation model
>         - SpaceTest -- a simple model to test spaces, displays, and more
>           importantly, probes. It is also a good experiment as a framework
>           that includes all possible spaces (except networks) and allows the
>           user to dynamically select the appropriate one.
>
>Remaining tasks:
>
>         - Multi2DHexaGrid
>         - Multi2DHexaTorus
>         - Ordered2DHexaGrid
>         - Ordered2DHexaTorus
>         - Multi2DHexDisplay
>         - NetworkHexaGridDisplay
>
>         for testing purposes:
>
>         - updating SpaceTest to include the multiple occupation spaces.
>         - finalizing and completing the sporadic jUnit tests I have now.

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

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

Hi Everybody,

First of all, thanks for all for the comments. As it turned out, I could
not wait for them and went along with the implementation before even
getting them. That means, that I missed the good points, but I
figure the space lib will eventually be reshaped anyway, so perhaps,
we could incorporate these improvements later. (Or I'll do that, but I
am a bit constrained now in terms of time.)

Anyway, below are my comments!

Cheers, Gulya

At 02:58 PM 11/24/01 -0800, Skye Bender-deMoll wrote:
>  >classes getXXXNeighbors (XXX=VonNeumann or Moore) and findMaximum/
> >findMinimum have _two_ extent parameters. (One for the horizontal
> >and one for the vertical extent.)
>
>I think the original intent of the hex substrate is to reduce the
>asymetries caused by the a square lattice which necessitate the vonN/More
>distinction.  But it seems like it would be very useful to make it possible
>to specify the "radius" of the hex ngh for max/min, etc.

>And as a kludge to stay in complience with the 2dspace, define moore to be
>all of the hex neighbors out to that radius, and VonN as the alternating
>adjacent cells?  Actually  the radius concept is usefull in square lattice
>as well.  Radius of 1 = VonN, Radius of sqrt(2) equals Moore..  In other
>words, asume the parameters describe the axes of an ellipes, and include in
>the ngh all cells who's center point falls on or within the ellipse.  This
>interpretation can easily be ported to hex and presumably any other space
>shape.  Would this be a good time to look at the GIS architecture in light
>of possible future compatibility?  Of course, trade off is that if you have
>to do that much calculation to determine who your neighbors are, you might
>as well be in a vector space!  Always tradeoffs I guess...

I tend to like the radius approach better than the alternating cell one.
(I'd expect that those would be different on a hexagonal grid, but I am
not sure.) What I currently have implemented is rather stupid. I kept
the getVonNeumannNeighbors() method and company, because I wanted
to descend my class from the normal grid space. (This may not be
an ultimately good decision, but for this version it does it.) They are,
however, in this version, equivalent to the newly introduced getNeighbors(),
findMinimum(), etc., respectively.

On the front of the horizontal/vertical extents, I was fairly radical. In the
new methods I only have one radius parameter. The old methods
(i.e. getVonNeumann... and co) simply pass the greater extent forward.
This is a very rough approximation, I admit, but the underlying idea is
that they will eventually get removed if we'll have a better root class.
That is, the bottom line here is that currently, we don't have a base
class with the getNeighbors(), findMinimum, etc. functionality in it
(without reference to the specific structure of the space). I think,
that would be necessary. In the meanwhile, I used Object2DGrid
as this base class, wherever I could.
[I kept myself away from the repast sources, everything is currently
under a separate package hierarchy. I regret it now, but I started
the whole thing on a laptop, which did not have all the tools needed
for building repast, installed.]

That said, I liked the idea of using an oval (with two radiuses).
Of course, that would bring a serious efficiency penalty, especially
as I managed to figure out a relatively fast way to get the neighbors
if there is only a single radius. (The algorithm has the additional
nice property that it returns the neighbors in ascending order of
distance.) But I think this method could still remain there, to
speed up the special case.

>Also, I agree with mike that it would be good to take another look at the
>diffusion approximation (literature search?) although the hex should do
>much better than square lattice did.

Well, I did not do my homework... :-) On the other hand, I think, I have
managed to figure out the essence of the original approximation and
mirrored it in a hexagonal context. (I was a bit confused about the
weighting in the average, but I got rid of that altogether as the
hexagonal space is fairly even and it seems to work nicely.)

I agree, however, that the reading part of it should also be done.
Which, I promise, I'll do, but as I said, there are some very
unfortunate constraints on my available time now... :(

Well, thank you all, again!


>-just my 2cents
>  -skye
>
> >Send Repast-developer mailing list submissions to
> >        rep...@li...
> >
> >To subscribe or unsubscribe via the World Wide Web, visit
> >        https://lists.sourceforge.net/lists/listinfo/repast-developer
> >or, via email, send a message with subject or body 'help' to
> >        rep...@li...
> >
> >You can reach the person managing the list at
> >        rep...@li...
> >
> >When replying, please edit your Subject line so it is more specific
> >than "Re: Contents of Repast-developer digest..."
> >
> >
> >Today's Topics:
> >
> >   1. More on the space lib (technicalities) (Laszlo Gulyas)
> >   2. RE: More on the space lib (technicalities) (North, Michael)
> >
> >--__--__--
> >
> >Message: 1
> >Date: Wed, 21 Nov 2001 17:12:05 -0500
> >To: Nick Collier <vze...@ve...>
> >From: Laszlo Gulyas <gu...@la...>
> >Cc: rep...@li...
> >Subject: [Repast-developer] More on the space lib (technicalities)
> >
> >
> >
> >Hi All,
> >
> >I've continued my work on hexagonal spaces and came across a couple of
> >new issues.
> >
> >First of all, it turns out that, in the end, I might need to revise my
> >earlier musings
> >on the design of the space classes. (:-)) The problem is that in the
> >original grid
> >classes getXXXNeighbors (XXX=VonNeumann or Moore) and findMaximum/
> >findMinimum have _two_ extent parameters. (One for the horizontal
> >and one for the vertical extent.) In terms of the hexa grid, however, I am
> >having
> >hard time to come up with a meaningful interpretation of these. This 
> would not
> >be a problem in itself, but this means that it is going to be hard to 
> create a
> >common interface for these classes. (That is, unless we keep the core
> >functionality only in the interface and put this additional functionality
> >into the
> >respective subclasses.) What would be your advice on this?
> >
> >Second, I am having problems with the Diffuse2D class. I thought, I could
> >provide a hexagonal version of this class, too. My problem, however, is
> >that the diffusion rules seem somewhat awkward to me. Any idea how
> >they should be implemented on a hexagonal grid? Or at least, what they
> >are based on? (Except that they are based on Swarm. :-))
> >
> >Finally, I noticed that the compareMax.compareMin methods are private
> >in Object2DGrid. Any reason these should not be available to subclasses?
> >(I can live with them as they are, I am just wondering if I overlooked
> >something.
> >It would be nice to know, since I am designing my own space classes, and
> >certainly I want to learn from what is already in the lib.)
> >
> >Thanks!
> >
> >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
> >
> >
> >
> >--__--__--
> >
> >Message: 2
> >From: "North, Michael" <no...@an...>
> >To: 'Laszlo Gulyas' <gu...@la...>, Nick Collier
> >         <vze...@ve...>
> >Cc: rep...@li...
> >Subject: RE: [Repast-developer] More on the space lib (technicalities)
> >Date: Wed, 21 Nov 2001 16:26:02 -0600
> >
> >
> >As a note, the interface java.awt.Shape allows arbitrary shapes to be
> >defined.  It could be used as an advanced extents parameter.
> >
> >Hexagonal, or other types of diffusion, could be based a discrete
> >approximation to the diffusion equations for a continuous space.  These
> >types of approximations have been extensively used in finite element
> >analysis.
> >
> >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
> >
> >
> >-----Original Message-----
> >From: Laszlo Gulyas [mailto:gu...@la...]
> >Sent: Wednesday, November 21, 2001 4:12 PM
> >To: Nick Collier
> >Cc: rep...@li...
> >Subject: [Repast-developer] More on the space lib (technicalities)
> >
> >
> >
> >
> >Hi All,
> >
> >I've continued my work on hexagonal spaces and came across a couple of
> >new issues.
> >
> >First of all, it turns out that, in the end, I might need to revise my
> >earlier musings
> >on the design of the space classes. (:-)) The problem is that in the
> >original grid
> >classes getXXXNeighbors (XXX=VonNeumann or Moore) and findMaximum/
> >findMinimum have _two_ extent parameters. (One for the horizontal
> >and one for the vertical extent.) In terms of the hexa grid, however, I am
> >having
> >hard time to come up with a meaningful interpretation of these. This would
> >not
> >be a problem in itself, but this means that it is going to be hard to create
> >a
> >common interface for these classes. (That is, unless we keep the core
> >functionality only in the interface and put this additional functionality
> >into the
> >respective subclasses.) What would be your advice on this?
> >
> >Second, I am having problems with the Diffuse2D class. I thought, I could
> >provide a hexagonal version of this class, too. My problem, however, is
> >that the diffusion rules seem somewhat awkward to me. Any idea how
> >they should be implemented on a hexagonal grid? Or at least, what they
> >are based on? (Except that they are based on Swarm. :-))
> >
> >Finally, I noticed that the compareMax.compareMin methods are private
> >in Object2DGrid. Any reason these should not be available to subclasses?
> >(I can live with them as they are, I am just wondering if I overlooked
> >something.
> >It would be nice to know, since I am designing my own space classes, and
> >certainly I want to learn from what is already in the lib.)
> >
> >Thanks!
> >
> >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
> >
> >
> >_______________________________________________
> >Repast-developer mailing list
> >Rep...@li...
> >https://lists.sourceforge.net/lists/listinfo/repast-developer
> >
> >
> >
> >--__--__--
> >
> >_______________________________________________
> >Repast-developer mailing list
> >Rep...@li...
> >https://lists.sourceforge.net/lists/listinfo/repast-developer
> >
> >
> >End of Repast-developer Digest
>
>
>
>_______________________________________________
>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] Re: More on the space lib (technicalities)

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

On Wed, 2001-11-21 at 17:12, Laszlo Gulyas wrote:
> 
> 
> Hi All,
> 
> I've continued my work on hexagonal spaces and came across a couple of
> new issues.
> 
> First of all, it turns out that, in the end, I might need to revise my 
> earlier musings
> on the design of the space classes. (:-)) The problem is that in the 
> original grid
> classes getXXXNeighbors (XXX=VonNeumann or Moore) and findMaximum/
> findMinimum have _two_ extent parameters. (One for the horizontal
> and one for the vertical extent.) In terms of the hexa grid, however, I am 
> having
> hard time to come up with a meaningful interpretation of these. This would not
> be a problem in itself, but this means that it is going to be hard to create a
> common interface for these classes. (That is, unless we keep the core
> functionality only in the interface and put this additional functionality 
> into the
> respective subclasses.) What would be your advice on this?

I think Skye's suggestion seem reasonable here. Also, as you imply, the
getNeighbors and findMin/Max methods are not defined in Discrete2DSpace.
So, I'm perfectly happy if they exist only in the subclasses. As I've
said before we need to re-think the whole space library in light of
Gulya's work on spaces and Tom's work with repast and gis.

> Second, I am having problems with the Diffuse2D class. I thought, I could
> provide a hexagonal version of this class, too. My problem, however, is
> that the diffusion rules seem somewhat awkward to me. Any idea how
> they should be implemented on a hexagonal grid? Or at least, what they
> are based on? (Except that they are based on Swarm. :-))

I'm afraid not. The Diffuse2D class was one the first I wrote for
repast. It is nearly a direct port of the one in Swarm and was only
written primarily for heat bugs. As Skye suggests a literature search is
probably necessary here.

> Finally, I noticed that the compareMax.compareMin methods are private
> in Object2DGrid. Any reason these should not be available to subclasses?
> (I can live with them as they are, I am just wondering if I overlooked 
> something.
> It would be nice to know, since I am designing my own space classes, and
> certainly I want to learn from what is already in the lib.)
> 

I agree these should be protected. I've made the changes in CVS.

Nick

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

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

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

 >classes getXXXNeighbors (XXX=VonNeumann or Moore) and findMaximum/
>findMinimum have _two_ extent parameters. (One for the horizontal
>and one for the vertical extent.)

I think the original intent of the hex substrate is to reduce the
asymetries caused by the a square lattice which necessitate the vonN/More
distinction.  But it seems like it would be very useful to make it possible
to specify the "radius" of the hex ngh for max/min, etc.

And as a kludge to stay in complience with the 2dspace, define moore to be
all of the hex neighbors out to that radius, and VonN as the alternating
adjacent cells?  Actually  the radius concept is usefull in square lattice
as well.  Radius of 1 = VonN, Radius of sqrt(2) equals Moore..  In other
words, asume the parameters describe the axes of an ellipes, and include in
the ngh all cells who's center point falls on or within the ellipse.  This
interpretation can easily be ported to hex and presumably any other space
shape.  Would this be a good time to look at the GIS architecture in light
of possible future compatibility?  Of course, trade off is that if you have
to do that much calculation to determine who your neighbors are, you might
as well be in a vector space!  Always tradeoffs I guess...

Also, I agree with mike that it would be good to take another look at the
diffusion approximation (literature search?) although the hex should do
much better than square lattice did.
-just my 2cents
 -skye

>Send Repast-developer mailing list submissions to
>        rep...@li...
>
>To subscribe or unsubscribe via the World Wide Web, visit
>        https://lists.sourceforge.net/lists/listinfo/repast-developer
>or, via email, send a message with subject or body 'help' to
>        rep...@li...
>
>You can reach the person managing the list at
>        rep...@li...
>
>When replying, please edit your Subject line so it is more specific
>than "Re: Contents of Repast-developer digest..."
>
>
>Today's Topics:
>
>   1. More on the space lib (technicalities) (Laszlo Gulyas)
>   2. RE: More on the space lib (technicalities) (North, Michael)
>
>--__--__--
>
>Message: 1
>Date: Wed, 21 Nov 2001 17:12:05 -0500
>To: Nick Collier <vze...@ve...>
>From: Laszlo Gulyas <gu...@la...>
>Cc: rep...@li...
>Subject: [Repast-developer] More on the space lib (technicalities)
>
>
>
>Hi All,
>
>I've continued my work on hexagonal spaces and came across a couple of
>new issues.
>
>First of all, it turns out that, in the end, I might need to revise my
>earlier musings
>on the design of the space classes. (:-)) The problem is that in the
>original grid
>classes getXXXNeighbors (XXX=VonNeumann or Moore) and findMaximum/
>findMinimum have _two_ extent parameters. (One for the horizontal
>and one for the vertical extent.) In terms of the hexa grid, however, I am
>having
>hard time to come up with a meaningful interpretation of these. This would not
>be a problem in itself, but this means that it is going to be hard to create a
>common interface for these classes. (That is, unless we keep the core
>functionality only in the interface and put this additional functionality
>into the
>respective subclasses.) What would be your advice on this?
>
>Second, I am having problems with the Diffuse2D class. I thought, I could
>provide a hexagonal version of this class, too. My problem, however, is
>that the diffusion rules seem somewhat awkward to me. Any idea how
>they should be implemented on a hexagonal grid? Or at least, what they
>are based on? (Except that they are based on Swarm. :-))
>
>Finally, I noticed that the compareMax.compareMin methods are private
>in Object2DGrid. Any reason these should not be available to subclasses?
>(I can live with them as they are, I am just wondering if I overlooked
>something.
>It would be nice to know, since I am designing my own space classes, and
>certainly I want to learn from what is already in the lib.)
>
>Thanks!
>
>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
>
>
>
>--__--__--
>
>Message: 2
>From: "North, Michael" <no...@an...>
>To: 'Laszlo Gulyas' <gu...@la...>, Nick Collier
>         <vze...@ve...>
>Cc: rep...@li...
>Subject: RE: [Repast-developer] More on the space lib (technicalities)
>Date: Wed, 21 Nov 2001 16:26:02 -0600
>
>
>As a note, the interface java.awt.Shape allows arbitrary shapes to be
>defined.  It could be used as an advanced extents parameter.
>
>Hexagonal, or other types of diffusion, could be based a discrete
>approximation to the diffusion equations for a continuous space.  These
>types of approximations have been extensively used in finite element
>analysis.
>
>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
>
>
>-----Original Message-----
>From: Laszlo Gulyas [mailto:gu...@la...]
>Sent: Wednesday, November 21, 2001 4:12 PM
>To: Nick Collier
>Cc: rep...@li...
>Subject: [Repast-developer] More on the space lib (technicalities)
>
>
>
>
>Hi All,
>
>I've continued my work on hexagonal spaces and came across a couple of
>new issues.
>
>First of all, it turns out that, in the end, I might need to revise my
>earlier musings
>on the design of the space classes. (:-)) The problem is that in the
>original grid
>classes getXXXNeighbors (XXX=VonNeumann or Moore) and findMaximum/
>findMinimum have _two_ extent parameters. (One for the horizontal
>and one for the vertical extent.) In terms of the hexa grid, however, I am
>having
>hard time to come up with a meaningful interpretation of these. This would
>not
>be a problem in itself, but this means that it is going to be hard to create
>a
>common interface for these classes. (That is, unless we keep the core
>functionality only in the interface and put this additional functionality
>into the
>respective subclasses.) What would be your advice on this?
>
>Second, I am having problems with the Diffuse2D class. I thought, I could
>provide a hexagonal version of this class, too. My problem, however, is
>that the diffusion rules seem somewhat awkward to me. Any idea how
>they should be implemented on a hexagonal grid? Or at least, what they
>are based on? (Except that they are based on Swarm. :-))
>
>Finally, I noticed that the compareMax.compareMin methods are private
>in Object2DGrid. Any reason these should not be available to subclasses?
>(I can live with them as they are, I am just wondering if I overlooked
>something.
>It would be nice to know, since I am designing my own space classes, and
>certainly I want to learn from what is already in the lib.)
>
>Thanks!
>
>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
>
>
>_______________________________________________
>Repast-developer mailing list
>Rep...@li...
>https://lists.sourceforge.net/lists/listinfo/repast-developer
>
>
>
>--__--__--
>
>_______________________________________________
>Repast-developer mailing list
>Rep...@li...
>https://lists.sourceforge.net/lists/listinfo/repast-developer
>
>
>End of Repast-developer Digest

RE: [Repast-developer] More on the space lib (technicalities)

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

As a note, the interface java.awt.Shape allows arbitrary shapes to be
defined.  It could be used as an advanced extents parameter.

Hexagonal, or other types of diffusion, could be based a discrete
approximation to the diffusion equations for a continuous space.  These
types of approximations have been extensively used in finite element
analysis.

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


-----Original Message-----
From: Laszlo Gulyas [mailto:gu...@la...]
Sent: Wednesday, November 21, 2001 4:12 PM
To: Nick Collier
Cc: rep...@li...
Subject: [Repast-developer] More on the space lib (technicalities)




Hi All,

I've continued my work on hexagonal spaces and came across a couple of
new issues.

First of all, it turns out that, in the end, I might need to revise my 
earlier musings
on the design of the space classes. (:-)) The problem is that in the 
original grid
classes getXXXNeighbors (XXX=VonNeumann or Moore) and findMaximum/
findMinimum have _two_ extent parameters. (One for the horizontal
and one for the vertical extent.) In terms of the hexa grid, however, I am 
having
hard time to come up with a meaningful interpretation of these. This would
not
be a problem in itself, but this means that it is going to be hard to create
a
common interface for these classes. (That is, unless we keep the core
functionality only in the interface and put this additional functionality 
into the
respective subclasses.) What would be your advice on this?

Second, I am having problems with the Diffuse2D class. I thought, I could
provide a hexagonal version of this class, too. My problem, however, is
that the diffusion rules seem somewhat awkward to me. Any idea how
they should be implemented on a hexagonal grid? Or at least, what they
are based on? (Except that they are based on Swarm. :-))

Finally, I noticed that the compareMax.compareMin methods are private
in Object2DGrid. Any reason these should not be available to subclasses?
(I can live with them as they are, I am just wondering if I overlooked 
something.
It would be nice to know, since I am designing my own space classes, and
certainly I want to learn from what is already in the lib.)

Thanks!

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


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

[Repast-developer] More on the space lib (technicalities)

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

Hi All,

I've continued my work on hexagonal spaces and came across a couple of
new issues.

First of all, it turns out that, in the end, I might need to revise my 
earlier musings
on the design of the space classes. (:-)) The problem is that in the 
original grid
classes getXXXNeighbors (XXX=VonNeumann or Moore) and findMaximum/
findMinimum have _two_ extent parameters. (One for the horizontal
and one for the vertical extent.) In terms of the hexa grid, however, I am 
having
hard time to come up with a meaningful interpretation of these. This would not
be a problem in itself, but this means that it is going to be hard to create a
common interface for these classes. (That is, unless we keep the core
functionality only in the interface and put this additional functionality 
into the
respective subclasses.) What would be your advice on this?

Second, I am having problems with the Diffuse2D class. I thought, I could
provide a hexagonal version of this class, too. My problem, however, is
that the diffusion rules seem somewhat awkward to me. Any idea how
they should be implemented on a hexagonal grid? Or at least, what they
are based on? (Except that they are based on Swarm. :-))

Finally, I noticed that the compareMax.compareMin methods are private
in Object2DGrid. Any reason these should not be available to subclasses?
(I can live with them as they are, I am just wondering if I overlooked 
something.
It would be nice to know, since I am designing my own space classes, and
certainly I want to learn from what is already in the lib.)

Thanks!

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

[Repast-developer] Re: hex space

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

On Mon, 2001-11-19 at 14:25, Laszlo Gulyas wrote:
> 
> Hi,
> 
> I get the feeling that I might have been somewhat offending in pressing
> this issue. If that's the case, please accept my apologies.

No offense taken at all. Its important to press issues like this. There
are several places in repast that hinder the movement from a conceptual
model of a simulation to its implementation in code. The implementation
of concepts like "spaces" should reflect a conceptual model of an agent
space, rather than their implementation as collections. More work on
this sort of thing will make it much easier to move from a conceptual
model to the code for that model. And that I think should be one of
"guiding lights" for future repast development. All this is to say that
I'm very glad and appreciative that you are thinking along these lines.

Anyone else have comments on spaces in repast?

Nick

> 
> Gulya
> 
> > > >I'm willing to make major additions and within reason some changes to
> > > >the current space library. What would be nice is a new architecture
> > > >along the lines of what you've been talking about that could be used in
> > > >conjunction with the current one. The current space code could be
> > > >deprecated, although perhaps not in the java sense, and users would be
> > > >encouraged to use the new one. If you'd like to take the lead on this,
> > > >feel free.
> > >
> > > I am not sure I understand this. Are you thinking of a completely disjoint
> > > space hierarchy, or space classes that implement several interfaces or
> > > something comletely different?
> >
> >What I'm thinking is a new design nearly from scratch and this would
> >also require new gui displays classes as well. You've pointed out
> >several conceptual problems in the space library and I don't think these
> >can be rectified by shoe-horning in new code, especially if we want to
> >incorporate the ideas from your longer musings on spaces.
> >
> >Nick
> >
> >--
> >Nick Collier
> >Social Science Research Computing
> >University of Chicago
> >http://repast.sourceforge.net
> 
> --
> 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

[Repast-developer] Re: hex space

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

At 10:24 AM 11/19/01 -0500, Nick Collier wrote:
>[...]
> > I think, only one part of my point is that the alternate design would allow
> > the use of tools with menus. More importantly, however, I think that the
> > neighborhood model is _really_ an identifying part of the space. A grid
> > with Moore neighborhood is just _not_ the same as a grid with von Neumann
> > neighborhood.
>
>I agree with you, but (there's always a but) when I originally wrote the
>space library I was incorrectly thinking of spaces as merely collections
>and the neighborhood code as various ways to get elements from those
>collections (in the same way that you can do pop() and some what
>inchorently get(int index) on a java.util.Stack). The current library
>doesn't reflect the neighborhood model as an identifying part of the
>space. This was poor design on my part, not fully understanding the
>agent modeling domain. A re-design of the space library would take this
>into account.

Hi,

I get the feeling that I might have been somewhat offending in pressing
this issue. If that's the case, please accept my apologies.

I really don't think that the original design was poor, or anything. The
fact is that it was (and still _is_) the 'state of the art' in agent-based
simulation. The issue here is that agent-based simulation is an evolving
subject and we all try to do work that keeps up with its evolution.

Taking me for example, I've been doing agent-based modeling and
I've been developing tools for it for the last 5 years or so, but the
ideas I've recently expressed did not come to me until a few months
ago. (Moreover, I am not entirely sure what I will be thinking of all this
5 years from now. :-))

So, in general, I agree with everything you wrote in this mail (above
and below), but thought it would worth pointing out that no offense
was intended.

Gulya

> > >I'm willing to make major additions and within reason some changes to
> > >the current space library. What would be nice is a new architecture
> > >along the lines of what you've been talking about that could be used in
> > >conjunction with the current one. The current space code could be
> > >deprecated, although perhaps not in the java sense, and users would be
> > >encouraged to use the new one. If you'd like to take the lead on this,
> > >feel free.
> >
> > I am not sure I understand this. Are you thinking of a completely disjoint
> > space hierarchy, or space classes that implement several interfaces or
> > something comletely different?
>
>What I'm thinking is a new design nearly from scratch and this would
>also require new gui displays classes as well. You've pointed out
>several conceptual problems in the space library and I don't think these
>can be rectified by shoe-horning in new code, especially if we want to
>incorporate the ideas from your longer musings on spaces.
>
>Nick
>
>--
>Nick Collier
>Social Science Research Computing
>University of Chicago
>http://repast.sourceforge.net

--
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] Re: hex space

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

See below.


On Mon, 2001-11-19 at 09:59, Laszlo Gulyas wrote:
> 
> On the other hand, I think, the idea of a Discrete 2D space must be much
> broader than just grids with the two neighborhoods above. I can think of more
> than just the hexagonal spaces as an addition.

Your right. That's why I'd like to have a new space library that
eventually replaces the old. 

> 
> >On your ideas about defining Grids and Torii via their neighborhood
> >behavoir (e.g. Object2DMooreGrid), this is reasonable as far as client,
> >that is, agent behavoir code is concerned. For those of you just tuning
> >in, the idea here is that agent behavoir stays the same (i.e
> >getNeighbors()) across a variety of spaces. My concern though is that
> >now the setup code will have to change according to which space is
> >required, and I'm not sure what is gained in the short term. You are
> >correct about the long term though, tools with menus etc.
> 
> I think, only one part of my point is that the alternate design would allow
> the use of tools with menus. More importantly, however, I think that the
> neighborhood model is _really_ an identifying part of the space. A grid
> with Moore neighborhood is just _not_ the same as a grid with von Neumann
> neighborhood.

I agree with you, but (there's always a but) when I originally wrote the
space library I was incorrectly thinking of spaces as merely collections
and the neighborhood code as various ways to get elements from those
collections (in the same way that you can do pop() and some what
inchorently get(int index) on a java.util.Stack). The current library
doesn't reflect the neighborhood model as an identifying part of the
space. This was poor design on my part, not fully understanding the
agent modeling domain. A re-design of the space library would take this
into account.

> >I'm willing to make major additions and within reason some changes to
> >the current space library. What would be nice is a new architecture
> >along the lines of what you've been talking about that could be used in
> >conjunction with the current one. The current space code could be
> >deprecated, although perhaps not in the java sense, and users would be
> >encouraged to use the new one. If you'd like to take the lead on this,
> >feel free.
> 
> I am not sure I understand this. Are you thinking of a completely disjoint
> space hierarchy, or space classes that implement several interfaces or
> something comletely different?

What I'm thinking is a new design nearly from scratch and this would
also require new gui displays classes as well. You've pointed out
several conceptual problems in the space library and I don't think these
can be rectified by shoe-horning in new code, especially if we want to
incorporate the ideas from your longer musings on spaces.

Nick

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

[Repast-developer] Re: hex space

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

At 09:29 AM 11/19/01 -0500, Nick Collier wrote:
>Hi,
>
>I'm just now replying to Gulya's queries about a hexagonal space. I
>never saw the original message, and just grabbed it from the archives.

Hi,

Thanks for the answer. My comments follow below.


>So, on your first question on whether a hexagonal space should be a
>descendant of Discrete2DSpace. The semantics of a Discrete2DSpace at
>least as it is defined in the current API revolve around whether the
>space is amenable to x, y coordinates and whether it is possible to
>choherently get a BaseMatrix (uchicago.src.collection.BaseMatrix) from
>such a space. The latter is obviously related to the former. If a
>hexagonal space can be thought of in terms of rows and columns then I'd
>descend from Discrete2DSpace, if not then something else.

Sure, x and y coordinates are the normal way to address hexagonal spaces.
That's what led me to raise the point in the first place.


>On VonNeumann and Moore, I don't think we can move these anywhere,
>although you are probably correct that these are incoherent for some
>Discrete2DSpaces. As parts of the public API they need to stay where
>they are.

Yes, I understand you don't want to alter the API right away. In fact, I only
asked for the consideration of later redesign and gradual migration.

On the other hand, I think, the idea of a Discrete 2D space must be much
broader than just grids with the two neighborhoods above. I can think of more
than just the hexagonal spaces as an addition.

>On your ideas about defining Grids and Torii via their neighborhood
>behavoir (e.g. Object2DMooreGrid), this is reasonable as far as client,
>that is, agent behavoir code is concerned. For those of you just tuning
>in, the idea here is that agent behavoir stays the same (i.e
>getNeighbors()) across a variety of spaces. My concern though is that
>now the setup code will have to change according to which space is
>required, and I'm not sure what is gained in the short term. You are
>correct about the long term though, tools with menus etc.

I think, only one part of my point is that the alternate design would allow
the use of tools with menus. More importantly, however, I think that the
neighborhood model is _really_ an identifying part of the space. A grid
with Moore neighborhood is just _not_ the same as a grid with von Neumann
neighborhood.

>I'm willing to make major additions and within reason some changes to
>the current space library. What would be nice is a new architecture
>along the lines of what you've been talking about that could be used in
>conjunction with the current one. The current space code could be
>deprecated, although perhaps not in the java sense, and users would be
>encouraged to use the new one. If you'd like to take the lead on this,
>feel free.

I am not sure I understand this. Are you thinking of a completely disjoint
space hierarchy, or space classes that implement several interfaces or
something comletely different?

>Lastly, in order for the hexagonal space to be included in repast,
>you'll need to write some JUnit unit tests. Ask me and/or see the README
>and code in uchicago/src/sim/test for more info. These don't take long
>and allow me to sleep better at night.

That's fine. I tend to like jUnit anyway. :-)
I might take me some more days to deliver the classes, however...

Gulya

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

--
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] hex space

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

Hi,

I'm just now replying to Gulya's queries about a hexagonal space. I
never saw the original message, and just grabbed it from the archives.

So, on your first question on whether a hexagonal space should be a
descendant of Discrete2DSpace. The semantics of a Discrete2DSpace at
least as it is defined in the current API revolve around whether the
space is amenable to x, y coordinates and whether it is possible to
choherently get a BaseMatrix (uchicago.src.collection.BaseMatrix) from
such a space. The latter is obviously related to the former. If a
hexagonal space can be thought of in terms of rows and columns then I'd
descend from Discrete2DSpace, if not then something else. 

On VonNeumann and Moore, I don't think we can move these anywhere,
although you are probably correct that these are incoherent for some
Discrete2DSpaces. As parts of the public API they need to stay where
they are.

On your ideas about defining Grids and Torii via their neighborhood
behavoir (e.g. Object2DMooreGrid), this is reasonable as far as client,
that is, agent behavoir code is concerned. For those of you just tuning
in, the idea here is that agent behavoir stays the same (i.e
getNeighbors()) across a variety of spaces. My concern though is that
now the setup code will have to change according to which space is
required, and I'm not sure what is gained in the short term. You are
correct about the long term though, tools with menus etc. 

I'm willing to make major additions and within reason some changes to
the current space library. What would be nice is a new architecture
along the lines of what you've been talking about that could be used in
conjunction with the current one. The current space code could be
deprecated, although perhaps not in the java sense, and users would be
encouraged to use the new one. If you'd like to take the lead on this,
feel free.

Lastly, in order for the hexagonal space to be included in repast,
you'll need to write some JUnit unit tests. Ask me and/or see the README
and code in uchicago/src/sim/test for more info. These don't take long
and allow me to sleep better at night. 

Nick

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

[Repast-developer] Discrete2DSpace and its descendants

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

[It seems this message did not get through to the list yesterday. Sorry, if 
it finally
gets there twice...]

Hi,

You know, I am that guy obsessed with spaces (see my note recently sent to the
repast-interest list). ;-) Despite my 'visions' described there, I am 
currently spending
some time on developing hexagonal spaces for Repast. In the course of this, 
however,
I found a couple of issues that I think would worth discussing here.

First, I think, the hexagonal spaces should be descendants of 
Discrete2DSpace. Do you
agree?

I suppose you do [you'll let me know if I am wrong :-)]. Then the question 
comes up
whether the constants 'VON_NEUMANN' and 'MOORE' should be kept declared in
Discrete2DSpace. (I.e. those are meaningless concepts in hexagonal spaces, at
least, as I understand them.)

This is a minor issue, I admit, but the same logic surfaces in the 
implementations of
the Object2D* family, too. That is, functionality of those classes 'come in 
pairs'. E.g.
there is getVonNeumannNeighbors() and a getMooreNeighbors(), too. Same with
findMaximum*Neighbor() and company.

This can be seen as a minor issue, too. I'd simply need to kept my method 
names
clean from those specifiers and I'd be alright. Sure. But my real point is 
that this design
of the 2D space library implies that one cannot simply switch from one 
space to another
(or in case of Grids and Tori from one neighborhood-model to another), 
without changing
the behavioral code /of the agents/ itself).

What I would suggest instead, is to have a proliferation of spaces (e.g.
Object2DVonNeumannGrid and Object2DMooreGrid, etc). I know, this is kind of
cumbersome, but has the potential advantage that  -- in case of certain 
models --
one would be able to switch from one space to another without touching the 
behavioral
code...

Let me explain why I bother... What I envisage (well, that seems to be the 
state
of my mind, sorry... :-)) is some coding pattern and maybe a later tool, 
too, which
would allow to code a certain family of models, simply by selecting a space 
(and
perhaps an agent type) and providing the very basic behavioral rules. Then, 
if one
wants to have a go at another space, she would only need to select another one
'from the menu'.

The behavioral rules could certainly be formulated in terms of calls like
'findMaximumNeighbor()' or 'getNeighbors()', but hardly if the 'commands'
explicitely refer to space-dependent properties (like the VonNeumann and
Moore neighborhood).


Well, I think, I over-explained it already. One more thing. I know, the main
dilemma here could be that one does not want to change the interface of
one of the most important underlying libraries. But perhaps this could be
done by the coming of some major release. And in the meanwhile, we
could discuss whether it would worth it at all.

Best regards,

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

[Repast-developer] Discrete2DSpace and its descendants

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

Hi,

You know, I am that guy obsessed with spaces (see my note recently sent to the
repast-interest list). ;-) Despite my 'visions' described there, I am 
currently spending
some time on developing hexagonal spaces for Repast. In the course of this, 
however,
I found a couple of issues that I think would worth discussing here.

First, I think, the hexagonal spaces should be descendants of 
Discrete2DSpace. Do you
agree?

I suppose you do [you'll let me know if I am wrong :-)]. Then the question 
comes up
whether the constants 'VON_NEUMANN' and 'MOORE' should be kept declared in
Discrete2DSpace. (I.e. those are meaningless concepts in hexagonal spaces, at
least, as I understand them.)

This is a minor issue, I admit, but the same logic surfaces in the 
implementations of
the Object2D* family, too. That is, functionality of those classes 'come in 
pairs'. E.g.
there is getVonNeumannNeighbors() and a getMooreNeighbors(), too. Same with
findMaximum*Neighbor() and company.

This can be seen as a minor issue, too. I'd simply need to kept my method 
names
clean from those specifiers and I'd be alright. Sure. But my real point is 
that this design
of the 2D space library implies that one cannot simply switch from one 
space to another
(or in case of Grids and Tori from one neighborhood-model to another), 
without changing
the behavioral code /of the agents/ itself).

What I would suggest instead, is to have a proliferation of spaces (e.g.
Object2DVonNeumannGrid and Object2DMooreGrid, etc). I know, this is kind of
cumbersome, but has the potential advantage that  -- in case of certain 
models --
one would be able to switch from one space to another without touching the 
behavioral
code...

Let me explain why I bother... What I envisage (well, that seems to be the 
state
of my mind, sorry... :-)) is some coding pattern and maybe a later tool, 
too, which
would allow to code a certain family of models, simply by selecting a space 
(and
perhaps an agent type) and providing the very basic behavioral rules. Then, 
if one
wants to have a go at another space, she would only need to select another one
'from the menu'.

The behavioral rules could certainly be formulated in terms of calls like
'findMaximumNeighbor()' or 'getNeighbors()', but hardly if the 'commands'
explicitely refer to space-dependent properties (like the VonNeumann and
Moore neighborhood).


Well, I think, I over-explained it already. One more thing. I know, the main
dilemma here could be that one does not want to change the interface of
one of the most important underlying libraries. But perhaps this could be
done by the coming of some major release. And in the meanwhile, we
could discuss whether it would worth it at all.

Best regards,

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

[Repast-developer] evolver news

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

Hi,

(I've cc'd repast-developer here because I thought Skye might be
interested in this).

I've just checked in the latest changes to evolver as well as an actual
model. The model is in .../evolver/samples. The model corresponds to the
"baseline model of Uniform Reinforcement" in Skyrms and Pemantle's "A
Dynamic model of social network formation", Proceedings of the National
Academy of Sciences, vol. 97, no. 16. Its a fairly simple model, but all
the behavoir is captured by evolver in only 17 lines of code. The
majority of the code is in the "dump" action in the model which dumps a
probabilty matrix to the screen.

This version of the evolver uses NQPy (Not Quite Python) as its
scripting language and its very easy to use and to follow. If you do run
the model note that it does dump alot of stuff to the console so be
prepared. Also, you'll need to change the project directory in the
project.


Nick

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

[Repast-developer] build.xml and cvs

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

Hi,

I just recently noticed that build.xml doesn't update correctly on cvs
checkins, and more importantly that we all will have our own version
which may not synch with the instructions in COMPILE. Consequently, I've
removed build.xml and added build.foo as template for a user's specific
build.xml. I also changed the compile instructions in COMPILE
appropriately.

Not an idea solution, but okay for now, given that doing a cvs update
destroyed by own build.xml (rather than just replacing it with Tom's).

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

[Repast-developer] cvs restructuring finished

[Nick C. <ni...@sr...>]

Hi,

I've finished restructuring cvs. It now looks like this:

Acme
docs
repast
  Acme
  uchicago
  build.xml
  COMPILE
repast-web
uchicago

The important addition here is the repast directory which now has the
Acme and uchicago source directories underneath it. The top level source
directories Acme and uchicago have been removed (the directories remain
but the contents have been removed, a quirk of cvs). I'll probably move
the docs directory sometime soon as well.

Its VERY important that you delete your working copies of uchicago and
Acme on your machines, and check out the repast module. The reason for
this is you can still commit changes from these directories, but they
won't be reflected in the new structure.

You can check out the entire thing with "cvs co repast" which will
checkout the repast directory and its contents above. So assuming I'm in
/home/nick/src and checkout repast I'll get a /home/nick/src/repast/..
Previously, I would have gotten a /home/nick/src/uchicago/.. so you may
need to adjust paths accordingly.

Nick

ps. Tom, I'm not sure where you have your working copy of repast, but if
its like my old setup then it will be mixed in with other stuff in the
uchicago directory. You should probably go through the uchicago dir and
delete all the CVS dirs in it and its subdirectories. I'm sure you know
all this, but just a word of warning.

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

[Repast-developer] cvs restructuring

[Nick C. <ni...@sr...>]

Hi,

Can y'all (actually I suppose this applies just to Tom) commit any code
you've been working on to the tree, and don't make anymore changes until
I'm done restructuring cvs.

Let me know when you've done your commits and I'll begin then. Once I'm
finished I'll let you know.

Nick

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

[Repast-developer] cvs restructuring

[Nick C. <ni...@sr...>]

Hi,

I'd like to restructure the repast cvs tree. At the moment, the various
source directories are on top which make it impossible to add files like
INSTALL etc. in the standard place. 

For the new structure we'd have something like:

repast-web
	- various files
repast
	- uchicago (src source files)
	- Acme (Acme source)
	- INSTALL (how to compile from source with ant and build.xml)
	- build.xml

As a consequence of this, we'd obscure the version info for the source.
That is, we should still be able to get, say, foo.java, but we'd get
uchicago/src/sim/foo.java instead of repast/uchicago/src/sim/foo.java.
All the files in the new structure would become ver1.1.

So, comments, questions?

Nick

ps. the current structure dates back from the earliest days of repast
and reflects my cluelessness with respect to cvs.

n.

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

Re: [Repast-developer] Re: hiding the schedule

[Lars-Erik C. <ced...@cf...>]

Nick: Great that you managed to integrate the shuffling mechanism. I would
suggest that the "EZ-model" class come with a seed and a hidden
distribution together with standard methods for int and double (uniform)
random numbers. Still it would be good if the user could plug in customized
distributions overriding the standard methods. Could this be easily
implemented? Cheers, L-E


>Thanks for the feedback. I've attached a new version with the shuffling
>in place. This does raise questions about how you want to handle the
>random seed, however.
>
>Nick
>
>On Thu, 2001-09-06 at 19:29, Laszlo Gulyas wrote:
>> Hi,
>>
>> First of all, I liked the SimpleModel class pretty much, so thanks for the
>> good work.
>> I'll give it some more thoughts during the coming days, though...
>>
>> At this point, the only thing which came up was the scrambling of the
>> agentList before each autoStep, in order to have the order in which the
>> agents are called randomized. I wonder whether this should also be
>>automated.
>> I understand that you could do that in preStep(), but may be, having a flag
>> for that,
>> too would be even easier.
>>
>> Best,
>>
>> Gulya
>>
>>
>> At 02:42 PM 9/6/01 -0400, Nick Collier wrote:
>> >Hi,
>> >
>> >I've attached the first cut of a base model class that attempts to hide
>> >the scheduling mechanism. (For those of you tuning in late, this is for
>> >teaching purposes although its probably applicable to a lot of current
>> >models as well). Its based on the tutorial TemplateModel by Lars-Erik and
>> >Gulya. The idea here is that the user subclasses SimpleModel and
>> >implements or overrides a few methods while SimpleModel takes care of the
>> >scheduling.
>> >
>> >The important pieces here are:
>> >
>> >1. The run*(), and *step() methods. The idea here is to split up the
>> >behavoir executed each tick into pre (preStep()), post (postStep()), and
>> >executing (step()) phases. So in the case of a cooperation game, the user
>> >would override the step() method to have the agents play the game, and the
>> >preStep() and postStep() would do any necessary prepartion or destruction.
>> >What actually executes each tick is preStep(), step() and then postStep().
>> >
>> >If autoStep is set to true, SimpleModel will execute the preStep(),
>> >autoStep() and then postStep(). autoStep() loops through the agent list
>> >calling step on each agent. For this to work the agents must implement the
>> >Stepable interface.
>> >
>> >2. The stopping time stuff. This was in the TemplateModel code so I
>> >assumed it was important and implemented it. The idea here is that the
>> >user can set the stopping time via a call to setStoppingTime in their
>> >model, and SimpleModel will schedule the model to stop when that tick has
>> >completed.
>> >
>> >So, is this enough? Do we need to include some random number
>> >initialization? Should SimpleModel be abstract and force people to
>> >implement buildModel()? Any other thoughts, comments, etc. are of course
>> >welcome.
>> >
>> >Nick
>> >
>> >
>> >Lars-Erik Cederman wrote:
>> >>Nick: This sounds like music to our ears! When do you think you might be
>> >>done with this new version? Gulya and I will be teaching RePast as of
>> >>October and we're obviously very keen to have a standardized hiding
>>mechanism.
>> >>We'd be more than happy to contribute ideas and code so that we can get
>> >>this one up and running very soon.
>> >>I should mention that Gulya has now arrived in Cambridge. His email
>> >>address is gu...@la....
>> >>Cheers, L-E
>> >>
>> >>
>> >>>Hi,
>> >>>
>> >>>I'm thinking for the next release of repast I'll add something along the
>> >>>lines of your tutorial model that hides the scheduler, and assumes a
>> >>>step method in the agents. I'd appreciate your thoughts on this.
>> >>>
>> >>>thanks,
>> >>>
>> >>>Nick
>> >>>
>> >>>--
>> >>>Nick Collier
>> >>>Social Science Research Computing
>> >>>University of Chicago
>> >>>http://repast.sourceforge.net
>> >>
>> >
>> >
>> >--
>> >Nick Collier
>> >Social Science Research Computing
>> >University of Chicago
>> >http://repast.sourceforge.net
>> >
>> >
>> >
>> >package uchicago.src.sim.engine;
>> >
>> >public interface Stepable {
>> >
>> >   public void step();
>> >
>> >}
>> >package uchicago.src.sim.engine;
>> >
>> >import java.util.ArrayList;
>> >
>> >public class SimpleModel extends SimModelImpl {
>> >
>> >   protected Schedule schedule;
>> >   protected ArrayList agentList;
>> >   protected String name = "A RePast Model";
>> >   protected String[] params = {""};
>> >   private long stoppingTime = -1;
>> >   private BasicAction stoppingAction;
>> >   protected boolean autoStep = false;
>> >
>> >   public void setStoppingTime(int time) {
>> >     stoppingTime = time;
>> >     if (stoppingAction != null) schedule.removeAction(stoppingAction);
>> >     if (schedule != null) setStopAction();
>> >   }
>> >
>> >   private void setStopAction() {
>> >     System.out.println(stoppingTime);
>> >     schedule.scheduleActionAt(stoppingTime, this,"stop", Schedule.LAST);
>> >   }
>> >
>> >   public void setup() {
>> >     stoppingTime = -1;
>> >     stoppingAction = null;
>> >     schedule = new Schedule();
>> >     agentList = new ArrayList();
>> >   }
>> >
>> >   public void begin() {
>> >     buildModel();
>> >     buildSchedule();
>> >   }
>> >
>> >   public String getName() {
>> >     return name;
>> >   }
>> >
>> >   public Schedule getSchedule() {
>> >     return schedule;
>> >   }
>> >
>> >   public String[] getInitParam() {
>> >     return params;
>> >   }
>> >
>> >   public void buildModel() {}
>> >
>> >   public void buildSchedule() {
>> >     if (autoStep) schedule.scheduleActionBeginning(1, this,
>>"runAutoStep");
>> >     else schedule.scheduleActionBeginning(1, this, "run");
>> >     setStopAction();
>> >   }
>> >
>> >   public void runAutoStep() {
>> >     preStep();
>> >     autoStep();
>> >     postStep();
>> >   }
>> >
>> >   public void run() {
>> >     preStep();
>> >     step();
>> >     postStep();
>> >   }
>> >
>> >   private void autoStep() {
>> >     int size = agentList.size();
>> >     for (int i = 0;i < size; i++) {
>> >       Stepable agent = (Stepable)agentList.get(i);
>> >       agent.step();
>> >     }
>> >   }
>> >
>> >   protected void preStep() {}
>> >   protected void step() {}
>> >   protected void postStep() {}
>> >
>> >   public static void main(String[] args) {
>> >     SimInit init = new SimInit();
>> >     SimpleModel model = new SimpleModel();
>> >     if (args.length > 0) init.loadModel(model, args[0], false);
>> >     else init.loadModel(model, null, false);
>> >   }
>> >
>> >}
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>>
>> --
>> Laszlo Gulyas, MSc
>> 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
>
>
>Attachment converted: Macintosh HD:SimModel.java (TEXT/ttxt) (0002413C)