linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: James Bruce <bruce@andrew.cmu.edu>
To: Jake Moilanen <moilanen@austin.ibm.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [ANNOUNCE 0/4][RFC] Genetic Algorithm Library
Date: Sat, 08 Jan 2005 09:19:42 -0500	[thread overview]
Message-ID: <41DFEBFE.1030602@andrew.cmu.edu> (raw)
In-Reply-To: <41DFE8B7.9070909@andrew.cmu.edu>

Ok I've read the patch and see you do indeed have crossover; Now I have 
a different question.  What is the motivation for generating two 
children at once, instead of just one?    Genes values shouldn't get 
"lost" since the parents are being kept around anyway.  Also, since the 
parameters in general will not have a meaningful ordering, it might make 
sense for the generic crossover to be the "each gene randomly picked 
from one of the two parents" approach.  In practice  I've found that to 
mix things up a bit better in the parameter optimization problems I've 
done with GAs.
   - Jim

James Bruce wrote:
> Do you have any crossover?  This is critical for GA to work well - 
> without it, the algorithm is really only a parallel random search.  More 
> specifically, is step 6 pure copies of a single parents, or can children 
> inherit tunables from multiple parents?
>  - Jim
> 
> Jake Moilanen wrote:
> 
>> ...
>> The basic flow of the genetic algorithm is as follows:
>>
>> 1.) Start w/ a broad list of initial tunable values (each set of
>>     tunables is called a child) 2.) Let each child run for a 
>> timeslice. 3.) Once the timeslice is up, calculate the fitness of the 
>> child (how
>> well performed).
>> 4.) Run the next child in the list.
>> 5.) Once all the children have run, compare the fitnesses of each child
>>     and throw away the bottom-half performers. 6.) Create new children 
>> to take the place of the bottom-half performers
>>     using the tunables from the top-half performers.
>> 7.) Mutate a set number of children to keep variance.
>> 8.) Goto step 2.
>>
>> Over time the tunables should converge toward the optimal settings for
>> that workload.  If the workload changes, the tunables should converge to
>> the new optimal settings (this is part of the reason for mutation). 
>> This algorithm is used extensively in AI.
> 
>  > ...
> 


  reply	other threads:[~2005-01-08 14:26 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-01-06 16:08 [ANNOUNCE 0/4][RFC] Genetic Algorithm Library Jake Moilanen
2005-01-06 16:14 ` [ANNOUNCE 1/4][RFC] " Jake Moilanen
2005-01-06 17:20   ` Cal Peake
2005-01-06 17:26     ` Cal Peake
2005-01-06 16:18 ` [ANNOUNCE 2/4][RFC] " Jake Moilanen
2005-01-06 16:22 ` [ANNOUNCE 3/4][RFC] " Jake Moilanen
2005-01-06 16:27 ` [ANNOUNCE 4/4][RFC] " Jake Moilanen
2005-01-08 14:05 ` [ANNOUNCE 0/4][RFC] " James Bruce
2005-01-08 14:19   ` James Bruce [this message]
2005-01-08 22:56     ` Jake Moilanen
2005-01-08 15:37 ` Pedro Larroy
2005-01-10 15:54   ` Jake Moilanen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=41DFEBFE.1030602@andrew.cmu.edu \
    --to=bruce@andrew.cmu.edu \
    --cc=linux-kernel@vger.kernel.org \
    --cc=moilanen@austin.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).