Re: [tablix-list] Source file genetic.c - 2nd part!

From: Tomaž Šolc <>
Date: Sun, 06 Sep 2009 17:34:40 +0200

Hash: SHA1

Hi Giovanni,

I agree with the changes you suggest and I would be happy to accept
patches that implement them.

More answers inline below.

> ...omissis...
> I have also noticed the followings:
> - it is never possibile to extend mutation to a larger part of half the
> population; since Tablix is a GA engine, I think it should permit all
> parameters combinations, even if strange.
> - it is not possibile to vary the population percentage used as parents
> I suppose that it could be of some interest to introduce one more
> control parameter to be able to modify this values too; keeping that
> mutation and randomization must be applied only on the parent part and
> children are produced by crossover procedure, I was thinking to modify
> the code and the help text, according to this one (this correct also the
> difference among code and help I was talking about):

Agree. I think having more knobs to tweak is a good thing, as long as
defaults work for most people.

> Nevertheless, I am not sure this could be really useful for the GA
> results: I have tried to search the mathematical details of Tablix GA,
> since I remember I have read them a long time ago in manuals but I did
> not succeeded to find and reread them to verify my hypothesis.
> Where can I find them? And, according to your experience, do you think
> it could be of some general interest that I modify genetic.c (adding
> parameter "parentpart" and modifying the other two) and send you the
> result (so, not just for my tests)?

There's no formal description of the genetic algorithm. Maybe you
remember this document? It's just a description of the type of problems
that can be solved with Tablix.

Also, this paper was my initial inspiration for writing Tablix:

>> I have also noticed the followings:
>> - mutations are made also on some individual with the highest fitness
>> since, at the start, the population is checked for sequences with same
>> fitness and some of these are raised to the maximum value; it seems to
>> me that these individuals will be overwritten soon by the next mating
>> phase, since they will be put at the end of population by the qsort
>> procedure; this means that those mutations could be useless. You could
>> introduce a cycle to repeat the draw of the individual to be mutated
>> when it hits that fitness. Anyway I don't know how many times this
>> could happen on each iteration.

This is true, such mutations are useless.

I thought that this happens so rarely that adding a special case
wouldn't affect the results too much. I don't remember whether this
decision was based on some measurements or not - maybe it would be worth
checking out again, what percentage of mutations is lost because of this.

Best regards
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla -

Received on Sun Sep 06 2009 - 17:34:47 CEST

This archive was generated by hypermail 2.2.0 : Mon Sep 07 2009 - 06:28:42 CEST