Douglas Roberts wrote:
> Agents in an ABM are (or should be*) software objects that correlate
> to their real-world counterparts at a level of resolution that is
> defined by the requirements of the problem to be solved by the
> simulation. [..]
As a practical matter, most object oriented programming involves stuff
that either acts or is acted upon.
I'm not very happy with that -- all these ad-hoc assignments to state
variables in objects. A simulation that does the same thing with
transformations of objects (including singletons like some shared space)
is a description of a process that is closer to math. Clear inputs and
outputs and specific mechanisms in between the two.
> [*Footnote from the (or should be) above: I know people who have
> written applications with no object-oriented technologies at all,
> using FORTRAN or C, (or worse, purely procedural Java) and who claim
> to have developed an ABM. I contend, that while they may have
> developed a really neato simulation, it isn't an ABM. Where are the
> agents? Rows of an array? Elements of a struct? An array of structs?
> I really don't think so.
Throw in some #omp for's above the loops on a parallel machine to get
non-determinism..
#include <stdio.h>
#include <stdlib.h>
#define MOSTFUEL 100
typedef struct agent { int work; int fuel; } agent_t;
void init (agent_t *agent) {
agent->work = 0;
agent->fuel = rand () % MOSTFUEL;
printf ("agent %p has %d units of fuel\n", agent, agent->fuel);
}
void step (agent_t *agent) {
if (agent->fuel > 0) {
printf ("agent %p working\n", agent);
agent->work++;
agent->fuel--;
} else {
printf ("agent %p out of juice\n", agent);
}
}
main ()
{
int N = 10;
int steps = 50;
int i, j;
agent_t *agents = malloc (sizeof (agent_t) * N);
if (!agents) abort ();
for (i = 0; i < N; i++) init (&agents[i]);
for (j = 0; j < steps; j++)
for (i = 0; i < N; i++) step (&agents[i]);
return 0;
}
>
> Sure, you can emulate an OO environment in C with structs and function
> pointers, and you can even call it an OO implementation. But it's not.
For example, an Objective C compiler just converts [obj msg] in user
source code into implicit C calls of sendMsg(obj,msg). sendMsg is just
an ordinary C function that uses a hash to get the right function
pointer. Then there is a bit of bookkeeping to set up the lookup
tables. Yes it could all be done in C with a few coding conventions,
such as with http://users.pandora.be/stes/compiler.html
> And please, let's save the topic of "object-oriented FORTRAN" for its
> own special flame war!]
Fortran 2003 seems like it could be a fine programming language for
agent models. It has all the common OOP features. An argument for
Fortran, I suppose, would be superior numerical performance. I doubt
it would be that big of a win, though, due to the fact that agent codes
tends to be rate limited by memory latency and CPU indirect mispredicts,
more than poor code generation of particular loops.
Consider the features of an implementation like this:
http://www.lahey.com/lf71/netwtpr1.htm
e.g.
module
! Define a type (class) called Greyhound that extends
! the Dog class defined in C# code below, and is part of
! the VirtualDog namespace
type, extends( VirtualDog%Dog ), namespace( VirtualDog ) :: Greyhound
contains
! Declare a class method (procedure); the 'pass'
! attribute makes it an instance (dynamic) procedure
procedure, public, pass :: Bark
end type Greyhound
contains
! Define the Bark method that overrides the inherited
! class' method; i.e., give the Greyhound its own bark
subroutine Bark( this )
! Declare the passed-object (hidden argument in the
! call statement) as the same type as the class
class ( Greyhound ) :: this
print *, "BOW WOW (Fortran Dog)"
end subroutine Bark
end module
============================================================
FRIAM Applied Complexity Group listserv
Meets Fridays 9a-11:30 at cafe at St. John's College
lectures, archives, unsubscribe, maps at http://www.friam.org
