Re: problems with using index

[Rick Riolo]

Did you send it to the index, or the list?
You want to send it to the *list*.
I tried it and it works for me.
 - 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 14:44:21 +1100
> From: Xiaodong Li <address@hidden>
> Reply-To: address@hidden
> To: address@hidden
> Subject: Re: problems with using index
> 
> At 07:17 PM 2/1/00 -0500, you wrote:
> 
> >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
> 
> Hi Rick,
> 
> The interesting thing is that I just tried with "getCount" (or "count") for 
> the index (keep in mind that it is an index for a "map" object), and I got 
> an error of "InvalidArgument", and it also points out "getCount" cannot be 
> recognised for some reason. I am not sure if anyone has just tried with 
> this or something similar.
> 
> Regards,
> 
> -- Xiaodong
> 
> 
> 
> >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.
> 
> 
>                   ==================================
>    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.