Re: ordering events in a swarm ....

[xueyue]

Marcus and Paul's comments (although they did not understood my
questions entirely) helped me to solve my problems: i.e. dynamically
creating new objects and run a schedule. The orginal ambiguity arose
because of my incomplete knowledge about
Schedule. I would not describe it again. Now, I would completely
describe my intention and my solution. Marcus seemed have better
solution, if any one is interested in his, 
please consult him. 
My intention:
a transport simulation system, in which there are n travellers
moving around network initially. So, each traveller start with 
-start action, and they will then create new actions at later 
times such as at 8:00am generate departure time, at 9:00am
move from home to school, etc.... All travellers can run with 
a dynamical scheduler:

schedule=[Schedule create: aZone];
[schedule setAutoDrop: 1];
schedule=[schedule createEnd];
....
create a list, agentList, of travellers of class Travellers
....
[schedule at: 0 createActionForEach: agentList message: M(start)];

[[schedule activateIn: nil] run];

This will work correctly (according to my expectation, i.e., 
-start will be executed at 0, new actions will be executed 
at their scheduled time, ....).

In transport simulation, the number of travellers on the network is not
fixed. We intended to generate new travellers 
randomly and hoped they could run in the same scheduler. I 
implemented in a wrong way (mainly I put the creator
after [[schedule activateIn] run]). As I said, Marcus has 
some fresh idea which I would test in future. But currently
I stick to the following implementation which I tested: 

schedule=[Schedule create: aZone];
[schedule setAutoDrop: 1];
schedule=[schedule createEnd];
....
//create a list, agentList, of travellers of class Traveller
....

[schedule at: 0 createActionForEach: agentList message: M(start)];


//... create a traveller creator, of class TravellerCreator, ...

[creator setSchedule: schedule];
[schedule at: 0 createActionTo: creator message: M(start)];
// creator has also a -start method.

[[schedule activateIn: nil] run];


TravellerCreator has the following method we are interested in here:

-start {
 id obj;
 ... create a new traveller, obj, at time t;
 [schedule at: t createActionTo: obj message: M(start)];
 ....
 //obviously: t>= getCurrentTime();

 [schedule at: getCurrentTime()+1 createActionTo: self 
    message: M(start)];
  //beware: two -start methods are different.

  return self;
}

In this way, 
(1) creator's -start will be excuted once when currentTime increase by
one (of cause, it could be scheduled in different 
way, for example, be excuted once when currentTime increased 
by two, or a random number).
(2) every time -start of creator is excuted, a traveller may 
be created, and scheduled in 'schedule'.
(3) my test has proved that new Traveller object's -start 
will be excuted at t. 










> >XH> existing objects' actions have been activated and run in an object
> >XH> 'schedule' of class Schedule, can any new object (they may be born
> >XH> at random times even after 'schedule'!) generate actions and put
> >XH> then in 'schedule' using: [schedule at: t createActionTo:
> >XH> newObject message: M(anAction)]?
> >
> >My advice is not to use `newObject', but to use a method,
> >-ensureTarget, that returns the object to be used in the future.
> >Putting this information in a method should help clarify to the reader
> >that the future target object is not something predetermined in your
> system,
> >and it will help focus your mind on describing to yourself (or to us)
> >how and why you come to want `newObject'.
> 
> Please clarify.  Are you saying that one should do something like:
>             [schedule at: t createActionTo:
>                             [someObject ensureTarget] message: M(anAction)];
> 
> I may be missing something, but I do not see how this guarantees all
> previous schedules remain in place,while adding a new one.
> 
> I followed this thread with interest, as I would *eventually* have to
> dynamically and randomly schedule and remove activities (behaviours)
> associated with new and old objects alike, over possibly finite time steps.
> I am not so sure now if I grasped it!
> 
> Thanks
> 
> William.
> 
>                   ==================================
>    Swarm-Support is for discussion of the technical details of the day
>    to day usage of Swarm.  For list administration needs (esp.
>    [un]subscribing), please send a message to <address@hidden>
>    with "help" in the body of the message.

-- 
Dr Xueyue Huang
Center for Transport Studies
Imperial College 
London SW7 2BU

(+44) 171 594 6037

vcard.vcf
Description: Card for Xueyue Huang