Re: [Swarm-Modelling] lifecycle requirements

[glen e. p. ropella]

Marcus G. Daniels wrote:
> The Swarm collections library provides a uniform interface for different
> sorts of containers, using dynamic messages to each object in the
> container.   Not sure what you mean by "explicitly named" here.  You
> don't have to declare these methods, just conjure up a selector which
> may or may not be really implemented by the objects in the set.
> In C# 2 or Java 5 you could use `generics' for homogeneous sets, or rely
> on an abstract superclass to declare interfaces for methods all
> subclasses will implement.   In C++ templates are available for
> high-performance specialization of a collection per its type. Providing
> a single interface to different container implementations is not a problem.

The point is that the agents interact by using the _language_ selectors
and method names instead of their own names (or names settled on by
their community).  Again, you're talking about programming constructs,
not modeling constructs.

By "explicitly named", I mean something like the following:

Object X responds to a method named "- (void) abc: (int) arg1;"  In a
typical ABM tool, in order to send that message to the agent, you have
to already have, find, or build, the selector for that method based on
the return value, the string "abc:" and the type of the argument.

I don't want that detail in my _model_.  I want another agent to be able
to speak "passTheSalt" or whatever and have it translated to:

   [X abc: arg1];

>> It's not the collective that I'm trying to get at, it's the post-facto
>> naming of the object that I'm after.  The collective gets together in
>> some pattern, an external agent perceives this collective and _labels_
>> the pattern as, say, a "whirlpool".  That external agent should then be
>> able to act upon that whirlpool without explicit knowledge of how to act
>> on any given constituent of the whirlpool.
>>   
> I agree this is an interesting problem.  I'm glad that is now clearly
> articulated.

[grin]  Well, it's still not clear to me that you've understood what I'm
trying to say because you keep bringing up programming concepts.

> [much deleted]
>> Same car, same door, same action, different lexicons.
>>   
> This is case is a much simpler to implement, so I'm not so sure it is
> the best example.   The post-factor naming may require a perceptual
> capability, a capability that integrates a range of data some of it
> dynamic and over a period of time.   So the notion of a lexicon is not
> just a mapping between static facts, it has to be a mapping between a
> lexicon of named things to procedures for detecting them, say as a 0th
> approximation a hash table of `closures' over the appropriate contexts.

Yes.  That's why I mentioned the process of discovering what an agent
responds to as well as the 2 layers.

>>> I'm puzzled by this.  As you know, this is not the case with Swarm.  
>>> The norm in Swarm is to use messages that have no knowledge of their
>>> destination until they get there.
>>>     
>> Actually, they have a great deal of knowledge of their destination.
>> They have to have a valid pointer to that destination or else the
>> program will crash with a seg fault.
>
> An agent and a task sent to it can both be invented or accessed by other
> agents during a simulation, not just when they are designed and
> compiled.  Messages, classes, and objects in Objective C are just stuff
> to pick up and use independently at runtime.
> But this whole notion of "is the language sufficiently dynamic?" is
> bogus provided a statically typed language provides a reflection
> capability.   E.g. in Java/Swarm we simply have a Selector class that
> uses Java reflection to find the methods that are needed, and then in
> the Swarm scheduler & probe mechanisms there exists ability to call or
> interrogate the things found by reflection.  I think it's really just a
> question of how easy it is, in practice, to do dynamic things when the
> need arises.

Perhaps it is a question of ease of use.  In that case, what I'm looking
for is just "syntactic sugar" that hides all the programming detail when
writing the logic inside any given agent.  When designing an agent, I
don't want to code things like:

   if (anObject respondsTo aSelector) then
      invoke the aSelector on anObject.

I want to design the agent's logic from that agent's perspective in that
agent's _language_.

But, I really do think that this is another layer on top of the
programming layer.  And this layer is _dynamic_ in the sense that a)
different agents have different languages (and their internal logic will
be written in those different languages, regardless of the programming
language on which it all rests) and b) the tokens of any 2nd level
language can refer to different things under different conditions.

>> And even if one believes that a good modeler must be a good
>> programmer, the two tasks (modeling and programming) are different
>> tasks.  And I think it's useful to consider the modeling problems
>> separately from the programming problems when discussing requirements.
>>   
> Agent modeling is concerned with synthesis of mechanisms to reproduce
> phenomena that can't be understood by independent study of components.  

Not necessarily.  You've described the synthetic method.  But, one can
just as well use ABM in the inductive method.

> But computer systems are  large and complex today, and further can
> display chaos themselves, so that many experienced users of computers,
> at least in some situations, don't really understand what happens in
> them any better than scientists do for `real world' phenomena.  For
> example, the network dynamics in a complex supercomputing application
> vs. a traffic jam on the highway.  So I'd argue in practice modeling and
> the process of making computers be more useful can often be similar
> activities..

I agree completely that they can be similar, _depending_ on the domain
being studied.  If what's being studied are computer systems (including
man-in-the-loop), then the act of modeling such referents is _very_
similar to programming.  But, even then systems architecture and the
issues that are relevant to that are different from the issues relevant
to, say, algorithm design.

If, however, what's being studied is, say, indigenous populations and
how trade emerges, then those models _should_ look very different from
typical computer programs.

-- 
glen e. p. ropella, 971-219-3846, http://tempusdictum.com
We must not allow the clock and the calendar to blind us to the fact
that each moment of life is a miracle and mystery. -- H. G. Wells