What *is* Time? (was Re: re getCurrentTime(): solved)

[glen e. p. ropella]

I moved this to the modelling list because it's really a very
large fuzzy issue versus an implementation issue.  I realize
that the boundaries between the two lists are not well defined,
yet; but, I'm trying to help that de-fuzzification.

Sven N. Thommesen writes:
 > Rick has accurately described my initial expectations,
 > given that (time-wise, at least) my app is not more
 > complex than Heatbugs.

Then I suppose that means we should re-evaluate the docs
and what they explain.  Of course, we'll need y'all to 
help us!

 > I can now hit my button before the sim starts, while
 > it is running, and while it is stopped, without any
 > rude surprises.

Good!  The point of the whole exercise is to get you to 
where you can do what you want, eh?

 > PS: Perhaps Glen could further muddy the waters: 
 > is it, in Swarm, possible for different (sub-)Swarms to
 > have their own sense of time get out of sync with
 > each other? [And how does the answer depend on 
 > whether we have serial or parallell Swarm? :-) ]
 > If they do, what is the relationship between such 
 > sub-swarm clocks and any master Global Time clock?
 > 
 > If the answer is yes, they *can* get out of sync,
 > then perhaps the macro is a dangerous thing that
 > shouldn't be there?

I can always count on Sven to just cavalierly pop open that can o'
worms.

First, the short form (correct me if I get anything wrong, Roger):

There is a "Relative Time" for each Swarm.  This is probably the time
that should be used inside subswarms.  For instance, the modelSwarm
has a "modelTime" that the agents inside that swarm should access.
These relative times will almost certainly get out of sync in a ||
Swarm.  But, that concern should be handled by the constraints that
will be specified for the given schedules inside each subswarm.
Examples of these constraints are the ability to have a a schedule in
a swarm containing a sequence of ConcurrentGroups with "DefaultOrders"
of Concurrent, Sequential, or Randomized.


The long form: 

There has been alot of consideration given to how these models are
integrated.  And while time may seem like an inherent feature of what
is happening in Swarm, it isn't intended as such.  What we're calling
the "logical model of concurrency" in Swarm is based on partially
ordered sets. (See *) This basis can be considered completely
independent of time.  Just because all processes implicitly contain a
concept of the "passage of time," doesn't mean they have to refer to
or be based upon time.

So, it's completely reasonable to think about all processes in terms
of the order of events.  These events can be ordered by any constraint
imaginable.... heat index, risk dependency, relationships, etc.

Now that i've gone quite off the deep end, I'll return to the
question: "Is it possible for different (sub-)Swarms to have their own
sense of time get out of sync with each other?"

Not only is it possible, but, it's preferable, since most real systems
have subsystems with clocks out of sync with each other.  They have
sync points, obviously.  One perfect example is a human-computer
interface.  The computer's polls on, say, the keyboard device are much
much faster than the human's strikes of the keys.  In fact, the
keystrokes of the human are some neurally generated sequence with some
(hopefully) random noise, which is certainly not "sync'ed" with the
computer's high frequency poll.  But, the two processes are forcibly
synced because any keystroke that may actually happen in between
polling events of the computer waits for the next cycle of the
computer.

This is an extremely simple synchronization.  Much much more
complicated sycing goes on in virtually any system we might want to
model.

So, on to the next point: "perhaps the macro is a dangerous thing that
shouldn't be there?"  Well, scissors are also dangerous in the hands
of running children? [grin] Seriously, yes I think the macro is very
dangerous.  But, I can't imagine telling users that there's no way to
get the absolute time of the simulation.  And, it is a useful tool,
especially if you have ever worked inside the paradigm where your
simulation contains a "truth" model and a "system" model.  In this
type of simulation, "error" plays a large role... And one can only
have "error" if one has "truth."

So, the macro should stay.  And it is dangerous.  But, it's a useful
tool.  We could either let new users run with the scissors and learn
the error of there ways after a couple of untoward accidents.... Or we
could prescribe restrictions on their behaviour for reasons they don't
understand and expect them to grow into that understanding.  Both
work; but, you come off as limited and pretentious in the latter.

glen
p.s. I'm aware that this was not well-written and may, as Sven
put it, "muddy the waters;" but, since I'm in manual writing 
phase, I felt it was a good chance to just toss out some things
that need to be said without being too self-critical of the way
they're said.  Any responses will help mold the way this subject
is handled in the manual.


* Sets upon which relationships are defined that don't have relevance
to all members of the set.  E.g. I can have a set of objects, some of
which are cows and some of which are cars.  I can have a partial order
relation, say, "produces-better-milk-than".  Then it makes complete
sense to say "cow1 produces-better-milk-than cow2"; but, it makes no
sense to say "car1 produces-better-milk-than car2".  But, it certainly
also makes sense to say that "cow2 produces-better-milk-than car1".



                  ==================================
   Swarm-Modelling is for discussion of Simulation and Modelling techniques
   esp. using Swarm.  For list administration needs (esp. [un]subscribing),
   please send a message to <address@hidden> with "help" in the
   body of the message.
                  ==================================