Re: remove actions from schedule

[Piebe de Vries]

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