swarm-support
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: incompatible types in assignment


From: glen e. p. ropella
Subject: Re: incompatible types in assignment
Date: Wed, 29 Jan 1997 11:10:22 -0700

> > ---------------------------------------------------------------------
> >   id <Schedule> schedule;
> >   id <List> agentList[10];
> >   int agentSpeed[10], sortedAgentSpeed[10], sortMap[10];
> >   int maxAgentSpeed;
> >
> >   schedule = [Schedule createBegin: [self getZone]];
> >   [schedule setRepeatInterval: 1];
> >   schedule = [schedule createEnd];
> >
> >   sortedAgentSpeed = sort(agentSpeed, sortMap);
> >   for (i=0; i<10; i++) {
> >     j = sortedAgentSpeed[i];
> >     while (j <= maxAgentSpeed) {
> >        [schedule at: j createActionForEach: agentList[sortMap[i]]
> >             message: M(step)];
> >        j += mod( sortedAgentSpeed[i],maxAgentSpeed)
> >     }
> >   }
> > -------------------------------------------------------------------
> 
> I have a few questions about the latter suggestion:
> 
> 1) why mod(A,B) when A is by definition smaller than B ?

So, I was tired when I wrote it, eh? [grin]

> 2) Presumably the idea of flattening the 'inner loop' of fast agent step
>    calls is used in order to save on 'merge' related overhead (i.e. with
>    one schedule there should be no need to call the mechanisms which
>    merge two schedules). Well, I'm wondering whether the overhead is being
>    avoided by flattening the inner loop and furthermore I'm wondering
>    whether that overhead is very large in the first place. Roger should
>    post something about this trade-off (i.e. does his library 'notice' the
>    case where no merging is necessary).

This is a good point.  Even presuming what I wrote above might work,
there might be an issue with respect to comparing the two ways of
doing things.

> 3) Of course there is a serious memory penalty for this approach (consider
>    the case where speedA=3 and speedB=10000 --> you would get a schedule
>    containing quite a few events...)

Memory's cheap. [grin]

> 4) You set the repeatInterval on a schedule to 1, but then you set actions
>    to occur at times greater than 1 --> presumably you meant:
> 
>      [schedule setRepeatInterval: maxAgentSpeed];

Yep.

> 5) Also, isn't i only supposed to iterate until 5? If not, then what is
>    in sortedAgentSpeed[5]?

Yep.  Again, my only excuse is too little sleep!

That's the spirit!  One of the reasons for having a mailing
list is to bandy alternate methods about.  Manor sufficiently
trashed my hacked method, thereby showing why Roger's scheduling
machinery is worth using.

glen


reply via email to

[Prev in Thread] Current Thread [Next in Thread]