[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