Re: problems with using index

[Xiaodong Li]

At 07:16 AM 2/1/00 -0500, you wrote:
>
>The object will not be in the list, and there will be
>no nil in the list, either.   Of course the removed object
>will still exist, until you drop it.   So it is "accessible"
>in that sense (if you save its address in some other place
>so you can still send it messages).
>
>I think what the doc is trying to say is that when
>you have a case like this:
>
>     a  b  c  d  e  f
>              ^
>where you just did an [index next] which returned (d),
>which you then removed.   if you then do an [index next]
>you will then get (e), not (f).
>

Rick,

Thanks for the help.  I guess i can see your point, but another question here
is what exactly in the "d" location in the above list? considering it has been
removed, but it is not a nil, plus the list still retains its pointer to this
position ... What if I start another search through the above list which still
has a size of 6 instead of 5? What would I get at "d" position?


>I don't know why the popsize was changed in the breeder example.
>I suspect because the author realized that 100 is a rather
>small size for a GA population.
>

What happens in Breeder is that the variable "popSize" was initialised with
100, but then in the "addPopulation", which is called during the
"buildObjects", somehow has changed the "popSize" to its double... The
"addPopulation" is as follows:

============================================================

// From protocol
//_______________________________________________________________________
-(void) addPopulation: (unsigned) _num {
                                // Adds new chromosomes to the population
                                // Set popSize variable
//_______________________________________________________________________

  unsigned i;
  for ( i = 0; i < _num; i++ ) {
    BinChromosome* gen;
    gen = [BinChromosome createBegin: [self getZone]];
    [[[gen setLength: chromLen] setRandomInit] setID: [Generator getNewName]];
    gen = [gen createEnd];
    
    [newPopList addFirst: gen];
  }
  popSize+= _num;
    
}
 
================================================================

Note that "_num" and "popSize" were both first initialised with 100, so after
"addPopulation" is called, the last line "popSize+=_num" basically changes
"popSize" to 200, then from this point onwards, when doing crossover (or
mating), everything is run based on this assumption of population size of 200
(see in the "-newGeneration" as listed partially below).  I am wondering why?

==================================================================
..........// more lines of code............. 
for ( i = 0; i < popSize*mut; i ++ ) {
      BinChromosome *gen, *parent;
      parent = [popList atOffset:
                          [uniformUnsRand getUnsignedWithMin: 0L 
                                          withMax:[popList count] - 1] ];

............// more lines of code............
===================================================================

Any advice?

Cheers,

-- Xiaodong
GSCIT
Monash Uni.
Australia


>- r
>
>Rick Riolo                           address@hidden
>Center for Study of Complex Systems (CSCS)
>4477 Randall Lab                
>University of Michigan         Ann Arbor MI 48109-1120
>Phone: 734 763 3323                  Fax: 734 763 9267
>http://www.pscs.umich.edu/PEOPLE/rlr-home.html
>
>On Tue, 1 Feb 2000, Xiaodong Li wrote:
>
>> Date: Tue, 01 Feb 2000 17:10:30 +1100
>> From: Xiaodong Li <address@hidden>
>> Reply-To: address@hidden
>> To: address@hidden
>> Subject: problems with using index
>> 
>> 
>> Can anyone here enlighten me?  
>> 
>> I have been looking at the Breeder 2.0.... The following is a part of it.
>> 
>> ======================================================
>>     // Kill the worst mutProb, and substitute them by the siblings of the
>>     // others
>>     i = 0; 
>>     index = [ popList begin: [self getZone]];
>>     [index setLoc: End];
>> 
>>     printf("killQuant is: %d and popSize is %d\n", killQuant, popSize);
>> 
>>     while( ( i < killQuant) && (stiff = [index prev] ) ){
>>       if ( verbose ) {
>>      printf("[%s %f]\n", [stiff getID], [stiff getFitness] );
>>       }
>>       [stiff drop];          // Eliminate gen
>>       [index remove];
>>       i++;
>>     }
>>     [index drop];
>> =======================================================
>> 
>> Here we use an index for "popList" which is a of type "map"....
>> 
>> In the above code, the stiff has been removed from "popList" after "[index
>> remove]".... Now my question is for popList, Is it true that a nil will be
>> placed at the position where the member "stiff" is removed, or the member
>> still can be accessed ?
>> 
>> The Swarm online help for "remove" is as follows:
>> 
>> "After a current member is removed, there is no member at the current index
>> location, but a subsequent next or prev message will continue with the same
>> member that would have been accessed had the current member not been
>> removed. An InvalidIndexLoc error is raised if the index is not positioned
>> at a current member."
>> 
>> What does it mean in the above "a subsequent next or prev message will
>> continue with the same member..."? I thought it has been removed, but why
>> can it still be accessed?
>> 
>> The reason I asked the above question is that I need to randomly select a
>> member of the popList later on. If it happens that a member is nil, then
>> there is potentially problems when using that member for doing cross-over
>> or something else.... 
>> 
>> The other thing puzzling me is that around the above code, the author of
>> Breeder 2.0 actually changed the variable "popSize" to doubled its original
>> size (eg., from 100 to 200). I am just wondering why.???
>> 
>> Your help is greatly appreciated...
>> 
>> --- Xiaodong
>> GSCIT
>> Monash University
>> Australia
>>  
>> 
>> 
>>                   ==================================
>>    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.
>> 
>> 
>
>
>                  ==================================
>   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.
>

=============================================
Dr. Xiaodong Li
Lecturer
Gippsland School of Computing and Information Technology
Monash University
Switchback Rd, Churchill 3842, Australia
Tel  : + 61 3 51226832          
Fax : + 61 3 51226879 
=============================================

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