[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