[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