Re: Initial schedule values

[Doug Donalson]

>
> concGroupType = [ConcurrentSchedule customizeBegin: [self getZone]];
> [concGroupType setAutoDrop: 1];
> concGroupType = [concGroupType customizeEnd];
>
> eventSchedule = [Schedule createBegin: [self getZone]];
> [eventSchedule setAutoDrop: 1];
> [eventSchedule setConcurrentGroupType: concGroupType];
> eventSchedule = [eventSchedule createEnd];
>
> It's not relevant to the question, but what are you trying to
> accomplish with this?  As soon as the second action is added with the
> same time on eventSchedule, the ConcurrentSchedule will bail.  The
> idea with ConcurrentSchedule is that it is subclassed to use other
> information (e.g. activation order), to determine how to sequence
> concurrent events.

Note that all of the following was developed by Roger to help me out with
asynchronous scheduling.

I schedule events by creating a "time" for the schedule and a "time" for the
subschedule.  I create the time by creating a time to next event that is
referenced from the present schedule time.  The time I create is a real
number.  It gets broken down into two timeval_t's.  The first of which is
the integer part of the real number and the other is the fractional part
multiplied by a "large" number that defines the precsion of the the
schedule. (Think right shift.)  So, if the time is 23765.00098765 then the I
have a time to next event of 23765 and a subschedule time of 98765 if my
precision multiplier is 10^8.  I then get the present schedule time and add
in the time to next event and   so

subSchedId=[eventSchedule insertGroup: (id) eventTime];

I then use the subschedule time to order the times within that group:

[subSchedId at: subScheduelTime createActionTo: aRedScale message: M(die)];

As far as I know, if an action to the schedule is created at a time already
in existance, then the system just recognizes that., and doesn't try to
create a new one.  In the event that two subschedule times are identical,
then that are treated the same way as a synchronous schedule, that is, first
come first served.  The idea of the precision is that having a high
definition within the fractional part of the subschedule makes the chance of
two events with an identical time very small, which is the purpose of an
asynchronous schedule.

> D3> Now suppose I immediately do the following operations (note the
> D3> schedule is not yet activated):
>
> index = [eventSchedule begin: [self getZone] ];
> actionAtTime = [index next]
> timeOfAction = (timeval_t) [index getKey]; // key of member is time value
>
> D3> What should the value "timeOfAction" of be?
> D3> My value seems to be 18 which might imply unilitialized.
>
> It should be the the time of the first scheduled action.  AutoDrop
> isn't relevant since nothing has been activated.  If no actions
> are scheduled, the value should be zero (actually, as a matter
> of style, you should really be checking the status of an index before
> blindly accepting values from getKey).

This is from code that you have already seen.  It is the code that Roger
wrote for me back in the Dark Ages (beta Swarm).  The object is to be able
to search the asynchronous schedule and correctly pick out the present
schedule and subschedule time.  It rquires a more detailed knowledge of the
scheduling code than I have to modify, so it is as it was so long ago.
However, other than the occasional bugs when Swarm has upgraded, it has had
no major problems.

Now, when my model is first setup, I create an initial number of
individuals.  Each will have a set of future events in their "lives".
Because this is a asynchronous simlation, the schedule is driven by these
events.  That means that the initial schedule must have a set of events
already scheduled when it is started.  (These are non-repeating events.)
The asynchronous schedule has returned "0" in the past in the non-activated
state, which is what I was expecting.  For some reason, it seems to be
returing "18" instead in some situations.  Now thta I know what the default
should be, I will see if I can find something I have done to screw it up.
(I believe that everything was fine until my latest mods, but I wanted to
make sure that I was correct on the default value.

Cheers,

   D3
>
>                   ==================================
>    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.
>


                  ==================================
   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.