Re: [Swarm-Modelling] lifecycle requirements

[glen e. p. ropella]

Marcus G. Daniels wrote:
> If the attributes and behaviors of an agent are a result of a sequence
> of filters, then the feature amounts to one of those books for children
> where one flap selects the head, another the torso, and another the
> legs.   This maps naturally to fixed named sub-interfaces and has the
> advantage that lifecycle changes can remain typed and dynamic method
> dispatch isn't, in principle, necessary.

That's not true, at all.  Defobj _does_ amount to that sort of
coarse-grained construction; but, a more general data-driven filtering
system would not.  The operators do not have to be limited to the
run-time assembly of methods.

>   Here, dynamic method dispatch
> provides nothing more than way to stall branch prediction in the CPU
> which is very bad.   As a modern CPU can have ten stage pipeline (or
> more), stalling it can mean losing a factor of ten or more in
> performance.  [Steve Railsback, et. al. wrote a comparison of agent
> based modeling toolkits, and Swarm did very poorly in some cases due to
> this when I looked at one of the cases with hardware profiling (Intel
> VTune).]   Either member functions (e.g. typed messages), or inline
> conditionals will be far more efficient.

As usual, you put optimization up front in the modeling task.  And
that's not the point.  It doesn't matter, from a modeling perspective,
how the feature is implemented as long as all the requirements are met.

Granted one requirement is efficiency.  And to the extent that we can
come up with a priority of requirements, we can weigh them against each
other.  In some cases efficiency might be paramount.  In others, ease of
specification might be paramount.  But, please don't assume a priority
before we even have the discussion.

> To put it another way, the existing hyperspace is implicitly small given
> the approach of `filters'.   To make the lifecycle features actually do
> something interesting, one must consider a large hyperspace.  In other
> words, mixing and matching at the DNA level, not at the organ or limb
> level.
> This notion of  `filters', came from a historical implementation
> constraints.  That is, that the `atomic' level is a method, and that
> (gee-wouldn't-it-be-great-if) methods could be assembled into classes in
> the fly.  With interpreters (e.g. in the R statistical package) or
> modern just-in-time compiler systems (Tamarin/JavaScript, Java virtual
> machine, or .NET CLR), code at the operator level can be written or
> mutated on the fly.   With runtime code generation, there is therefore
> the possibility to have DNA fragments of an agent really change
> behavioral microstructure.

As I said above, it doesn't matter if it's fine-grained code generation
or coarse-grained method selection.  Filtering still applies and, from
my perspective, don't come from historical implementation constraints at
all.

The technical and implementation differences surrounding fine-grained
vs. coarse-grained construction will be relevant _after_ we have a set
of requirements we want to meet.

> benign, but not that useful for modeling purposes.  But again, they
> *certainly do not* offer any efficiency gains, as you asserted some time
> ago, quite the contrary, in practice.

My assertion is that they were _intended_ to determine efficient data
structures based on modeling level specifications.  The fact that you've
identified an implementation detail that prevents them from actually
being efficient does not matter.  It's not relevant to this requirements
discussion.  You're conflating modeling with programming again.

---------------

So, now that we have that useless distraction out of the way, _is_
object evolution a requirement for an ABM tool?  And if so, which
packages do and don't currently facilitate it?

-- 
glen e. p. ropella, 971-219-3846, http://tempusdictum.com
I believe in only one thing: liberty; but I do not believe in liberty
enough to want to force it upon anyone. -- H. L. Mencken