Re: problems with using index

[Rick Riolo]

My example was meant to show what happens to the list
when you have an index "positioned" at (d), i.e., you did some
[index next]s until it returned the address of (d),
then you do the [index remove]  (not doing the drop first, as paul noted).
At that moment the list will be smaller; you can test
that by sending it a getCount message.
I believe (but check the swarm doc for indexes) that right
after removing that item, the index "points" to an undefined postion
such that if you do another [index next], you get (e).
There may even be some swarm-defined special value 
for that situation (as there are when its before the first
and after the last items, I think).

And if you start another index iteration thru the list,
the lis will have size 5, and the index will return
   a b c e f

As I said I don't know anything about the breeder package.
I was just speaking from a "domain expert's" point of view,
i.e., saying that running a GA with popSize 100 is pretty small,
so maybe the author just wants to start with 200.
But I am speaking without benefit of knowing the
package...

- 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 Wed, 2 Feb 2000, Xiaodong Li wrote:

> Date: Wed, 02 Feb 2000 10:09:50 +1100
> From: Xiaodong Li <address@hidden>
> Reply-To: address@hidden
> To: address@hidden
> Subject: Re: problems with using index
> 
> 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.
> 
> 


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