Re: Fw: [Swarm-Modelling] GEPR on life-cycle requirements

[glen e. p. ropella]

Marcus G. Daniels wrote:
> glen e. p. ropella wrote:
>> Well, just because some feature doesn't currently exist doesn't mean
>> it's not a basic or essential requirement.
>
> I'm glad to discuss this topic, but honestly, if it were essential to
> doing ABM at all, then people couldn't do ABM at all yet they do!  
> There are many ABM toolkits that have been around a long time, and that
> we'd have to struggle to articulate the requirement strongly suggests
> that "basic requirement" is not the right way to think about this. 
> What we are talking about is a better methodology or theory for ABM
> agent or collective transformations.  And better methodology is more
> than enough reason to proceed.

I disagree.  Perhaps we're using two different meanings for requirement.
 The essential requirement is object evolution.  And all the ABM
packages target this requirement (perhaps unconsciously).  The fact that
they succeed to some extent is what allows ABM to be done at all.  But,
that partial success doesn't mean that the requirement isn't essential.

I'm not talking about better methods (techniques), yet.  I'm talking
about bringing some clarity to the essential requirement of object
evolution.  That clarity can come about by examining how, to what
extent, and the origins for the various ABM tools' attempts to meet the
requirement.

As a contrasting example, Swarm, Repast, and JAS allow _any_ method to
be placed on the schedule, whereas Mason requires an explicit "step()"
method.  Both of these techniques come about due to a requirement for
object evolution.  In the Swarm-like case, you don't want to force an
object to implement a specific method, thereby allowing a kind of
semantic looseness.  In Mason, you don't want to corrupt your model with
excess "pragmas", thereby allowing you to make a modeling statement like
"this agent is _active_ in the schedule".

Both of those techniques decouple the object implementation from the
modeling semantics.  They just do it in different ways.  A requirements
discussion should be able to classify these techniques and show their
relationship to the core requirements.

>> We've seen a great deal of
>> progress in this direction already.  The ABM tools out there already
>> satisfy the object evolution requirement to _some_ extent.  But, we
>> don't know to _what_ extent.  That's why it would be nice to see some
>> people chime in about how well various tools meet the requirement (if,
>> indeed, others think its a requirement).
>>   
> Change it to "The ABM tools out there already can simulate object
> evolution to _some_ extent", and I'm happy to move on.

Well, since this is _all_ simulation and nobody is claiming to _emulate_
what really happens in the referent, it is vague to say that they all
simulate object evolution.

But, the main reason I say it the way I say it is because I think we
need to talk about requirements that are _met_, not phenomena that are
simulated.

-- 
glen e. p. ropella, 971-219-3846, http://tempusdictum.com
He who refuses to do arithmetic is doomed to talk nonsense. -- John McCarthy