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