Re: Swarm limitation?

[Sven Thommesen]

Brian George wrote:
> 
> To whom it may concern-
> 
>         I have been attempting to design a SugarScape simulation using Swarm.
> Unfortunately, I haven't been able to come up with a way in which to
> conveniently associate more than one value/object in a cell of a grid.
> For example, in my simulation I have a number of items that could be
> located at any postion in the world (the world is a Grid2d in all
> likelihood, right?):
> 
> Items that could be at a discrete position in the world:
>         bugs
>         pollution
>         resources (sugar, spice, etc...)
> 
> I could design this as in heatbugs, and have a Discrete2d object for
> each group of items, i.e. a bugs grid, a pollution grid.  These grids
> could then be displayed on a Lattice as in heatbugs.  The problem with
> this approach is that it is not very extensible in that each new type of
> item would require the user to define a new grid and "plug it in" to the
> existing simulation.  This is not straightforward and involves messy
> hacks into existing code (or at least it seems this way).
> 
> Another option would be to have a discrete grid of "MyCell" objects,
> where each Cell would contain the bugs, the pollution, the resources,
> etc.  In other words, all the data in one cell is encapsulated within a
> single object (the MyCell object).  It would seem, however, that
> problems arise when we start to think about how to display all this
> information.  Because each resource is no longer in its own Discrete2d
> object, there isn't any "automatic" method of display, is there?  Also,
> it would be nice to be able to display, for example, only the bugs and
> pollution on one lattice and the bugs and resources on another.  We
> considered maintaining another external Discrete2d that contained copies
> (or pointers or something) of the bugs, etc. contained in the cells.  In
> this way, you could access the bugs, etc. not only from the Cells, but
> also through this other Discrete2d object.  Unfortunately you run into
> the same problem as above, namely an explosion in the number of seperate
> classes and a lack of extensibility/maintainability.
> 
> Does anyone know of a good way to solve the problem of multiple values
> per cell?  I hope that I've described my problem well enough that some
> of you will have some ideas...I would guess that someone has had this
> problem before, however.
> 
> Thank you in advance,
> Brian George

Well, Brian, 

since nobody else felt compelled, I'll step up to the plate and provide my 2 
cents' 
worth. 

What you are concerned about is in principle (if not in implementation) two 
separate questions: how to represent your multi-attribute world *internally*, 
and 
how to represent it *externally* (graphically). 

I agree that the solutions to wanting the world to contain bugs, pollution, 
etc. 
(and a partridge in a pear tree :-) ) are either one Space per attribute, or a 
single Space containing a composite object. (The Grid2d space will hold either 
an 
integer or and id, which can point to an object, such as a List. Not directly 
possible is to fill it with real values (float, double)). What we want is 
obviously 
the most efficient organization with a view to minimizing run time -- but that 
might depend on the way in which your bugs need to access the attributes, and 
is 
not necessarily foreseeable by the Swarm designers.

FWIW, adding more attributes to the heatbugs model is not such a 'messy hack', 
once 
you've done it. Mostly it involves replicating a lot of code. I have an 
extended 
heatbugs model with 4 bug types and 3 attribute spaces -- I'll be happy to send 
you 
a copy if you're interested. (What *did* cause some head scratching and 
required 
handholding by Manor was my attempt to 'unpack' the model to where the 
ModelSwarm 
owns 4 BugSwarms, each of which owns a list of bugs. I finally got it right.)

The current version of heatbugs is unwieldy in that (as pointed out in the 
code) 
the world space object is not capable enough. As it is now, both the bugs and 
the 
heatspace have to know the size of the world, and both contain code to 
implement a 
'wraparound' universe. A better solution would be a general world object that 
would 
move the bugs, locate unoccupied spaces in a neighborhood, etc. Then the bug 
logic 
could be truly independent of how the world is implemented.

And at that point, we could let the world object 'own' the attribute spaces 
(which 
just makes sense from a philosophical standpoint, right? --at least, until you 
start futzing with bugs that have their own view of what the world's like ...) 
and 
mediate all questions about / changes to the attributes. Then the 
implementation (a 
grid of MyCells vs. multiple grids) could be made entirely 'behind the scenes' 
and 
purely for efficiency reasons.

Regarding the problem of graphical representation, my own model (see above) 
uses 
the available machinery: I have 3 Raster displays, each showing one 'heat' 
attribute plus the relevant bugs, and in addition a Raster showing all the bugs 
by 
themselves. I place each raster in a separate section of my virtual desktop, so 
that I can easily switch between them using Ctrl-<arrow>.

I am not sure how you would represent things otherwise -- after all, there's a 
limit to how much information you can pack into a little square! However, the 
current version of swarm lets you display not only colors on the squares, but 
also 
bitmaps (pixMaps) which you supply. (See demo app AntSort.) You could use a 
large 
number of pixmaps to display, depending on the state of each cell.

My own thought on reading your post was this: imagine a Raster display, with 
the 
following additions: along the left edge, on/off buttons which select which 
bugs to 
display. (These would operate independently, so that you could select all bugs 
if 
desired.) Along the right edge, buttons which choose which attribute (heat-) 
space 
to display; these would be mutually exclusive. Now you could easily change your 
display on-the-fly to focus on what you wanted to see. If you like my idea, 
lobby 
the Swarm gods ...

An interesting question is, given limited programmer resources, should the 
Swarm 
team emphasize efficient batch operation or glitzy (well, not to slant this too 
much, let's say 'intuitively helpful') graphical representations? The answer is 
not 
necessarily obvious ...

Cheers from the olympically hot&humid South,

Sven Thommesen
Auburn University
School of Human Sciences