Document: SCL: An Artificial Chemistry in Swarm
6.7 Access to Random State?
6 SCL Design Notes
6.5 Agent Update Order
An essential part of the requirement for SCL was to
support persistent storage of a model--i.e. being
able to save a model into a disk file, and reload it
later. This is not supported by any of the current
Swarm example applications, and there is little
support for it built into Swarm.
Swarm does provide object classes ObjectSaver
and ObjectLoader intended to take an arbitrary
object and save it or reload it. I experimented with
these, but eventually found them too cumbersome. They
operate by exploiting the Swarm probe machinery. Thus,
in order to control exactly what instance variables are
processed, it is necessary to establish appropriate
probeMaps. Further it is difficult to use
these methods in a way which easily respects the class
inheritance hierarchy. Finally, in some cases,
instance variables cannot be meaningfully saved to disk
in their normal form--because they are actually
pointers, and the same object will not generally be
guaranteed to be at the same location when the model is
reloaded (indeed, it would generally be highly
unlikely). In these cases it is necessary to
``re-code'' these variables in some sense. To do this
within the ObjectSaver and
ObjectLoader framework would mean developing
special ``proxy'' objects, to which
ObjectSaver and ObjectLoader could be
applied, but which would contain the ``re-coded''
instance variables. Given all these complications, I
abandoned this approach.
The strategy I adopted was to provide all relevant
objects with methods, saveTo: and
loadFrom:, which will save to or load from a
given disk file (implemented as a Swarm
OutFile or InFile object as
appropriate). The sclModelSwarm then provides
methods to get a file name, open the file, and invoke
the required saveTo: and loadFrom:
methods, in order, on all required objects. This
finally worked satisfactorily, but there were various
problems along the way:
- The InFile and
OutFile classes did not include methods for
all native types--specifically,
unsigned and BOOL. These were saved
in int form instead, but this is not robust
and obscures the code.
- The saving and loading methods
are not symmetrical; it is necessary to write extra
white space to guarantee correct reading.
- InFile and OutFile do not record the
types of the fields being stored, which makes it
harder to detect mismatches between the saving and
loading processes.
- The WorldRaster class has a bug, such
that, when dropped, it does not automatically cause
the corresponding widget to be dropped.
- To guarantee following exactly the same
trajectory after reloading a model, it is necessary
to store (and reload) the state of the underlying
random number generator. This is not directly
possibly with the standard Swarm generator. This is
discussed in more detail in the next section.
- Similarly, to guarantee following the same
trajectory on reloading, it is necessary that the
ordering of the agent lists be preserved. This is
somewhat tricky. It means, in particular, that the
SCL model must not be saved simply by scanning
the 2D space, and saving the particles in that order;
rather it must be done by scanning the agent lists,
and saving in that order instead.
- There is still an issue of how, exactly, to
``recode'' pointer information. In SCL the only
significant case of this was the pointers from bond
agents to L agents and vice versa. The
solution in this case was simply to recode the
pointers to L agents by their world co-ordinates.
The pointers could then be reconstructed on reload
(provided, of course, that the L particles are
reloaded, without any bond information, prior
to the bonds). The reverse pointers, from L
particles to bonds, can also then be re-constructed
as the forward pointers are re-established.
- There is a significant issue of what, if any,
state information is hidden in the Swarm scheduling
and activity machinery. There is no built-in support
for accessing this. In the case of SCL, which does
not make use of any advanced features of this
machinery, I finessed this problem by having the only
activity be to execute the step method on
sclModelSwarm. This object (and method) are
not changed by saving and/or reloading; this
variation is all hidden in other SCL objects, which
the activity machinery is not aware of. One small
side effect of this is that the ``model time'' cannot
be taken from the Swarm activity system (as it
continues to increase monotonically, regardless of
saving and loading operations). Instead, the
worldManager simply keeps its own
independent record of model time, which is
saved and/or reloaded as necessary.
6.7 Access to Random State?
6 SCL Design Notes
6.5 Agent Update Order
Document: SCL: An Artificial Chemistry in Swarm
Copyright © 1997 All Rights Reserved.
Timestamp: Tue Dec 31 19:40:38 GMT 1996
mcmullin@eeng.dcu.ie