Re: [Swarm-Support] development priorities (was Re: Membership in Swarm Developmen Group)

[glen e. p. ropella]

So, the SDG is finished being snide with me?  Thanks for that.  I
appreciate it when a member supported organization makes itself
approachable.

Marcus G. Daniels wrote:
> It seems to me there's a question of whether one wants to create ever
> more complex individual behaviors, or understand collections of simpler
> ones.   Is it the dynamics of a system that are interesting or
> elaborating the particular personalities in it?   Typically we come at
> ABM with the idea we know what an agent does but not what agents do
> collectively.   The point of simulating in the first place is that the
> analytics on the collection are not tractable.

Well, that's true in an ideal sense.  _Ideally_ we would know what the
agents do but not what they do collectively.  But, practically, that's
never the case.  In a practical project (even basic research), there's
always a game of "where to put the logic".

The point of simulation is to utilize brute force to help develop
analytics.  This is what makes simulation different from numerical
analysis, though numerical analysis often leads to the discovery of
analytic shortcuts, as well.

This part of the discussion belongs on the modeling list, though.

> So yes simulation is computationally expensive, and thus the appeal of a
> $700 machine that is ten times faster than a PC (a Cell-based
> Playstation 3).   It happens that the organization I work for is
> deploying a Cell-based petaflop computer, so as you might imagine I'm
> biased by that!

Sure.  But, support for a processor can more quickly be gained by using
the same technology of most people who want to use that processor.  And
my guess is that most people who want to use the Cell do NOT want to use
Swarm.  So, porting the current Swarm to the Cell will really just make
Swarm even more perverse and it won't increase the user base.

A better option would be to invest resources in a technology that others
will _help_ ensure runs on the Cell.  That way you're not doing all the
work yourself and you see a higher ROI.  The same argument applies to
porting Swarm to 64-bit architectures.  Why not use a technology that we
already _know_ is going to work there?

> I don't disagree that a reflective scheduler for both for simulation and
> analysis could be useful, but let's face it: Few people aggressively use
> the scheduling machinery that exists.  In some sense what you propose
> seems more appropriate for a game programming setting.

Well, my (unsubstantiated) claim is that people don't use the scheduler
because they can't understand what they're creating.  A scheduler
companion that helped "render" (if not reason over) the schedule would
help teach those users how to use the schedule purposefully.  After they
learn how to use it, they might use it.  Of course, they might _not_,
too, in which case my claim is false.  But, _I_ use fairly complicated
schedules and they help me write more efficient and more realistic
models; so, at least _I_ would use it. [grin]  Hence my particular bias.
 But, I also think there are plenty of people out there who are like me,
except they just can't justify putting the time and energy into learning
how to use the scheduler when they can "get by" with a simple schedule.

As for game programming, I partly agree.  But, the distinction between
gaming and simulation is tenuous at best.

-- 
glen e. p. ropella, 971-219-3846, http://tempusdictum.com
The fear of death follows from the fear of life. A man who lives fully
is prepared to die at any time. -- Mark Twain