Re: remove actions from schedule

[Doug Donalson;]

Piebe's comments on removing actions made me think that  
that my first email was a little unclear so let me explain further.  

In my simulation, agents are responsible for scheduling their own 
actions.  This is because actions too those individuals are 
what creates the new actions.  ie an adult host giving birth n
eeds to create a juvenile host and schedule a new time to birth 
for itself.

When an event is scheduled, the id for that event is returned by swarm
and I just make use of that and store it as part of the agent.  For 
example, a juvenile host (at present) has two possible events in its lifetime
molt into an adult and die, so there are two variables stored
deathEventId and moltEventId.  This costs nothing more than memory
which is very cheep right now.  If the juvenile dies of natural
causes the dieNatural message is sent and as part of it
 
[eventSchedule remove: moltEventId] is executed.

If the agent is munched then diePredation is sent
and remove's are sent for both events.

Prior to my SWARM days (when I wrote my owm schedules) this 
was much more effecient O(1) than a list search because the remove 
was direct, the remove went right to the object in the list.  I 
haven't looked at the SWARM implimentation so if remove: message does a 
complete list search then there is no difference in effeciency between 
the two methods.  (This is what you seem to imply is the SWARM 
implimentation.)  I would hope that if you know the event ID then a 
complete search is not necessary.

I found an extra benifit using this method however.  When
debugging, it is very useful to have as much of the state
of each agant available as posible, and this includes
the data about its active events.  I made a generic structure
for each scheduled event for each agent that includes 
schedule and subschedule times and schedule and subchedule 
event id's.  Like I said, RAM is cheep and my time is valuable.


Cheers,

    Doug

***************************************************************************
* Doug Donalson                          * Office: (805) 893-2962         *
* Ecology, Evolution, and Marine Biology * Home:   (805) 961-4447         *
* UC Santa Barbara                       * email address@hidden
* Santa Barbara Ca. 93106                *                                *
***************************************************************************
*                                                                         *
*   The most exciting phrase to hear in science, the one that             *
*   hearlds new discoveries, is not "EUREKA" (I have found it) but        *
*   "That's funny ...?"                                                   *
*                                                                         *
*       Isaac Asimov                                                      *
*                                                                         *
***************************************************************************


On Fri, 16 May 1997, Piebe de Vries wrote:

> The solution suggested by  Doug Donalson and Roger M. Burkhart on the
> problem of removing the right actions from an schedule
> 
> >    I don't know about the exact problem you are having, but I
> > think I know a simple way around it.  When your monkey creates
> > its actions, save the returned values (the ID of the action).
> > Then when you want to remove one of then you can use the message
> 
> > [modelSchedule remove: anAction];
> 
> does work but is, I think, not a very nice solution.
> 
> First a short description of the problem. We need a solution for:
> Actions are planned all the time and are removed from the schedule after
> they have been performed. If there are some planned actions for an
> object and the object is dropped, an error will occur if the actions are not
> removed  from the schedule, because the method will be sent to nothing.
> And of course this is not what we want.
> 
> We thought that we could remove each action to the object from the schedule
> before we removed it, but we could not implement this properly.
> The proposed method to achieve this is not more efficient than our way:
> The removal of an object's (i.e. a monkey's) actions from a schedule is,
> in this model, only necesarry when a monkey dies and, as a consequence,
> the Monkey-object needs to be dropped. For a monkey, this happens only
> one time, say after 500 time steps.  So there is a choice between:
> 
> 1. searching the schedule once for all actions of/to the Monkey and
> remove these actions. (What we tried to do).
> 
> or
> 
> 2. Sending messages from the planning object to the planned object in
> order to register the action (for later removal). Let the planned
> object keep track of each action performed by itself in order to
> remove the action from its list of planned actions (which again means
> going through a list). And this needs to be done for say more
> than 100 times. (What was suggested by Doug and Roger)
> 
> I think the first way is preferable above the second. Besides the
> efficiency, I do not see how to implement the second way if there can
> be more then one action planned and/or if a method can be invoked both
> from an action and directly from another object. Imagine an object
> with a  method which can both be planned (i.e. by use of an action) and be
> directly invoked without first planning. How in this case would the
> object know, after it performed the method, if it needed to remove an
> action. And when there is more than one action planned, how does it
> know which action exactly to remove.
> 
> I realise there are ways out of this also, but it would not improve
> the efficiency and the readability of the code. I also think it
> is not nice viewed from the concept of object orientated modelling
> that an object needs to occupy itself with the planning of its actions that
> much.
> 
> It would be nice to know how to remove the right actions from a
> schedule. But if there are other solutions to the problem of action to
> already dropped objects, it would even be nicer to know them.
> 
> Piebe de Vries
> 
> 
> -----------
> 
> 
> Roger M. Burkhart writes:
>  > > I tried to figure out what is exactly the things that are in the schedule
>  > > and how to remove only (and all) the actions of the monkey to be killed,
> but prefe
>  > > it doesn't work.
>  > > I keep running into the object actionConcurrent_c of which I do not
> understand
>  > > its funtcion.
>  >
>  > Doug Donalson already gave the right answer in his response: save the
>  > action returned by createAction when you first create it, and then remove
>  > this action (which you've saved inside the monkey data structure or
> wherever)
>  > directly from the schedule:
>  >
>  >   [modelSchedule remove: monkeySpecificAction];
>  >
>  > Doing it this way avoids the need to traverse through all the internal
>  > structure of a structure, including the actionConcurrent_c action you
>  > found that holds all the actions scheduled at the same time value.  It's
>  > likely to be faster, too.
>  >
>  > Doug: I'll answer your most recent questions on 2-tiered concurrent
> schedules
>  > after I get my example converted over.
>  > --
>  > Roger Burkhart
> 
>                   ==================================
>    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.
                  ==================================