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

[glen e. p. ropella]

joh> (1) In an older version of GA lib. by Merelo, they use "zone" for
joh> the argument for createBegin. i.e. as follows: gen =
joh> [BinChromosome createBegin: zone];

joh> Instead, I would like to use: gen = [BinChromosome createBegin:
joh> [self getZone]]

joh> What are the differences? (I'm using "zone" for my current
joh> version since I'm using old version of GA lib but...)

jmerelo> That's probably the correct way of doing it now. I don't
jmerelo> think there is a big difference, though, as far as zone =
jmerelo> [self getZone].

Just to add to JJ's comments.  When "zone" is used, it means
that there's been some variable (zone) that points to a valid
zone in which you may allocate new things.  We've been leaning
away from doing that because it distances the programmer from
where that varialble was set, making it difficult to keep track
of which zone it actually points to.  So, using [self getZone]
is more "Swarm-Style."  However, I'd like to point out that 
each [self getZone] *is* another message call and carries with
it the respective overhead.  So, it might be wise to have, say
inside an agent, something called "zoneImIn" that can be used.
(Mind you, I picked "zoneImIn" instead of something dangerous
like "myZone" so that the coder can delineate easily between
zones owned and operated by the agent and the zone in which the
agent sits.)

joh>     energySpent1 = -((double) (numInspected * inspectCost));
joh>     [self updatePersonEnergy: energySpent1];

joh> So I changed the above line as follows:

joh>   energySpent1 = -((double) (numInspected * inspectCost));

joh>   if (energySpent1 + [self getPersonEnergy] < 0.0) energySpent1 =
joh> 0.0; else if (energySpent1 + [self getPersonEnergy] > MAX_ENERGY)
joh> energySpent1 = MAX_ENERGY;

joh>   [self updatePersonEnergy: energySpent1];

joh> Then it works fine. Now wait! wait not so fast. :-)

joh> I already do have these guard statements of "ifs" in my
joh> updatePersonEnergy method as follows.

joh> -updatePersonEnergy: (double) v { double temp; if ((energy + v) <
joh> 0.0) energy = 0.0; else if ((energy + v) > MAX_ENERGY) energy =
joh> MAX_ENERGY; else energy = energy + v; return self; }

First off, you do know that setting energySpent1 equal to 0.0 is not
the same as setting energy equal to 0.0 inside the method, right?  In
the first code block, you are guaranteeing that updatePersonEnergy
will always get an argument between -[self getPersonEnergy] and
MAX_ENERGY-[self getPersonEnergy].  In the block of ifs inside the
method, you're modifying "energy" .... not "v" (which corresponds
to energySpent1 in the calling function).

Second, with the fix (the ifs in the calling function), you haven't
fixed upper bound at MAX_ENERGY.  What would happen is that if 
energySpent1 + [self getPersonEnergy] > MAX_ENERGY, then you are
going to send MAX_ENERGY into the updatePersonEnergy method.  So,
just because it's no longer bombing doesn't mean you've fixed it.

Now, the *real* problem you're facing is pretty hard to determine.
It could be the case that control is always going through one of
your ifs (in the calling function); hence, you would always be
sending either 0.0 or MAX_ENERGY into updatePersonEnergy.  I just
can't tell what's wrong from this.


joh> Hi Glen, This question is in the same thread as the second
joh> question of my last email about updateEnergy method in my
joh> program.

Does this mean that you no longer think you're bombing because
of large negative numbers?

Ken's suggestions are right.  If you're trying to tell if
a generically typed object ( id booga;) accepts a given 
message, use respondsTo:.  But, I claim that an identifier
should only be generically typed if it *has* to be.  I.e.
why do you want to generically type "tgt"?  Why not use
id <Person> tgt?

Also, you have to realize that the two methods for identifying
object/message mismatches are very different.  The respondsTo:
is a trap (like Ken said) that is done at run-time.  The 
protocol adherence is done at compile time.

Then there's also the issue of why your code isn't returning
a valid receiver from the 

  tgt = [world getObjectAtX: x1 Y: y1]

If it's not nil, which it shouldn't have if it made it into the branch
(plus the gdb trace you included said that the object was at
0x368b00), then *what* did it return?  Are there other objects that
can reside in the space?

But, aside from that:

(gdb) where
#0  objc_msg_lookup (receiver=0x368b00, op=0x278d10) at sarray.h:216
#1  0x41c2c in _i_Person__look (self=0x368880, _cmd=0x278b48) at Person.m:353
#2  0x404e0 in _i_Person__step (self=0x368880, _cmd=0x27934c) at Person.m:50

implies that the method being executed when the run bombs is
"look".  If you haven't found the answer, yet, it might help
to see the real code.

glen
p.s. Sorry I couldn't be more help this time around.