swarm-support
[Top][All Lists]
Advanced

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

Re: Using collections


From: Ken Cline
Subject: Re: Using collections
Date: Wed, 22 Jan 1997 21:20:15 -0500 (EST)

Glen,

(I meant to respond sooner, but was side-tracked for a few
days...  I'm sending this mainly just to clear up my
earlier question...)

Ah yes, I should have sent some code.  Sorry.

On each cycle of the simulation each agent performs its
"step" function (a la Heatbugs) within which it makes the
following method call:
     [self getNextGoal];

Then in the "getNextGoal" method we have:
   -getNextGoal {
       id next_goal;

       if ( [goalIndex getLoc] != End &&
            (next_goal = [goalIndex next]) != NULL )
          [self setGoal: next_goal];
       else
          [self setGoal: current_pos];
    }

(Note: this doesn't depend on the fact the Objective-C
supports short-circuiting =:-)

I started with just:

       if ( (next_goal = [goalIndex next]) != NULL )
          [self setGoal: next_goal];

but this will move the index past the end of the list and
cause a core dump if the agent continues to call the
"getNextGoal" function.

Another possiblity would be:

       if ( [goalIndex getLoc] != End )
          [self setGoal: [goalIndex next]];

but this will send a nil value to the "setGoal" function
when the end of the list is reached.  

Actually, it just occurred to me that I do trap that error
in the "setGoal" function...  hmm, should have thought of
that before I wasted your time...

Like I indicated, I sent this to clear up what I was asking;
your answers were very helpful and I've got something that
works.

Thanks!

Ken.

--------------------------------------
On Thu, 16 Jan 1997, glen e. p. ropella wrote:

> 
> [sorry about that... to finish...]
> 
> > 2. I've discovered that a list index doesn't perform any
> > bounds checking in the "next" method.  That is, if you call
> > [index next] when you are at the "End" of the list, then you
> > get a core dump.
> >
> >    However, [index getLoc] doesn't return "End" until after
> > you moved past the last list element.  Therefore, when I'm
> > traversing the list, I test two conditionals:
> >      ([index getLoc] != End) and ([index next] != nil).
> >
> >    Have I overlooked an more direct way of stopping at the
> > end of a list?  Is there a method to "peek" ahead without
> > moving the index?  Perhaps the "getOffset" method can be
> > used to accomplish this?
> 
> I'm not sure what the problem is, here.  The first statement I understand.
> If one has a list:
> 
>             1     next      2     next      3      next    4
>             --              --              --             --         
>            |i |                  |i |            |i |           |i |
>            |--|                  |--|            |--|           |--|
>   Index => |j |                  |j |            |j |           |j |
>            |--|                  |--|            |--|           |--|
>            |k |         Index => |k |            |k |           |k |
>             --                    --              --             -- 
>             End                   End   Index =>  End            End
>                                                  Index =>
> 
>                    ==> k           ==> End         ==> Core Dump
> 
> 
> But, the test for having already retrieved the last member of the 
> list can be done around the call to "next."  For example, from
> the docs, a usual use of the "next" message might be:
> 
>   index = [aCollection begin: aZone];
>   while ( (member = [index next]) ) {
>     // do something with member ...
>   }
> 
> In other words, the "next" transfer from state (2) to state (3)
> above should return 0 or NULL, which would break out of the 
> while loop in the code example.
> 
> But, more directly, you should be able to use:
> 
>    if ([list atOffset: [index getOffset] + 1]]) {
>       [ ... do whatever ...]
>    }
> 
> However, I would avoid doing anything like this because
> it relies on the constancy of the list (i.e. it hasn't 
> been changed) and that the index hasn't been manually moved
> around.
> 
> Let me know if you've done all this and you're still getting
> that behavior!  And code would help, also.
> 
> glen
> 
> 

_________________________________________________________
Ken Cline                             address@hidden
SAIC                                 VOICE (410) 571-0413
Annapolis, MD                          FAX (301) 261-8427




reply via email to

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