Menu
▾
▴
[Repast-developer] Re: Repast-developer digest, Vol 1 #24 - 2 msgs
|
From: <sky...@sa...> - 2001-11-24 23:00:06
|
>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 |
