swarm-support
[Top][All Lists]
Advanced

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

Re: "zone" or "getZone"? and one additiona question.


From: Ken Cline
Subject: Re: "zone" or "getZone"? and one additiona question.
Date: Sat, 15 Mar 1997 15:43:07 -0500 (EST)

On Sat, 15 Mar 1997, Jae Chan Oh wrote:

> In my Model Swarm, I create Person swarm initially -- say 10 of them.
> This time, I use,  person = [Person createBegin: [self getZone]];
> notice that here, "self" is model swarm.
> 
> Then when I create Person swarm on-the-fly, say by mating, I do that
> in Person swarm. This time I use:
>        child = [Person createBegin: createBegin: [self getZone]];
> 
> Now notice that "self" is person swarm.
> 
> This seems to introduce inconsistancies that some person swarm are created
> by sending message getZone to model swarm, and some are created by sending
> the message to person swarm. Is it a problem or does it matter?

Conceptually, I think a Person "belongs" to a particular
Person Swarm and hence it should be "created" in the Person
Swarm's zone.

So in ModelSwarm you could have:
    person = [ Person createBegin: [personSwarm getZone] ];

(I apologise if I've misunderstood you class structure or
your question...)

Note: make sure you've created personSwarm first!

Alternatively, you could create all your people in the
Person Swarm.  So now in ModelSwarm you could have:

    [ personSwarm addNewPerson ];

Is ModelSwarm maintaining a list of people? I gather it is;
in which case we need a reference to that new person passed
back to us by "addNewPerson".  That is, again in ModelSwarm,
you could have:

    person = [personSwarm addNewPerson];
    [ personList addLast: person ];

or simply:

    [ personList addLast: [personSwarm addNewPerson] ];

All that being said, I think this is a matter of personal
preference [no pun intended].



> My sencod question is related the "death in swarm".
> To intorduce death, in swarm, one of the suggestions in the swarm mailing 
> list 
> archive suggest to use a reaperQueue. Now do you think I would need to do that
> for birth as well? What I'm doing now is to create new child within Person
> swarm and add the child to the list of Person within Person swarm.
> Now, I could create a queue, say birthQueue, and do the similar things
> as in the case of death. i.e. add the new borns to the birthQueue but
> do not add it to the list of Person yet. Then when model swarm takes over,
> it add all new borns from birthQueue to the list of Person.
> Which method do you recommend?
> May be what I'm doing now causes all inconsitencies and core dump since
> I'm modifying the list of Person without letting Model Swarm know about it.

IMHO...

I don't think you have the problems adding to a list that
you have removing from it, namely dangling references to
dropped objects.

OTOH, a birthQueue does offer some possible advantages:

 - Controlling the time of birth, e.g. maybe you would
      rather have people born after a set number simulation
      cycles from their conception?  There would be other,
      perhaps simpler, ways of accomplishing this.

 - Gather statistics about birth


Ken.

_________________________________________________________
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]