eaml-design

[eaml-design] Initial focus

[Mariusz N. <ma...@ma...>]

Hi,

Thanks a lot Remon for your document.

Lets use plain text for discussions and LaTeX for the documents.
We can generate HTML from LaTeX and make it available on the EAML
web page at some stage.

I have discussed some of the EAML aspects with Grant Dick, which
I will summarize below.  Me and Grant are working in the same
department in the area of evolutionary computation.

There are quite a number of  aspects to EAML. As Remon said, the
separation of structure (template) from the actual parameter values is
an important one.


Structure
---------

What I mean by structure is: all the necessary descriptions to
instantiate population of individuals, randomize them, exchange the
state of the population (serialize individuals), instantiate all the
necessary operators.

There are some basic structural design decision to be made.

*) what is the basic elementary building block of the individual
genome? (single gene, single chromosome or a whole genome?)

I think the user should be free to specify it on a arbitrary
level. E.g.
- the genome is one chromosome which is a list of binary genes
- the genome is two chromosomes one of which is a list of genes with
integer numbers and the second is a list of genes with an alphabet
consisting of symbols  [A, B, C, D].
- the genome is one chromosome which is a tree-like structure
etc.

*) how the genetic structure is paired with "randomizer" and other
operators?

*) how the state of the genetic structure is expressed?

*) how we design the operators taxonomy?

We can have operators operating on: gene, chromosome, genome, and
group of individuals. Do we inline the operators into the genetic
structure description? Or do we "link" them externally?

*) Templating - as noted by Remon it is important to have a
possibility to do "templating", i.e. when describing the structure one
can use  parameters.


I think dealing with all the above is the current task. We need to
know how to: declare gene, chromosome, genome, individual type,
operators. Operator types should uniquely identify all well-known
operators (like "Uniform-distribution randomizer", or "Roulette Wheel
selection") - and this would be this "standardising" aspect of
EAML. All non-standard operators would need to be linked to the actual
implementation somehow.



Algorithm
---------

This is the tricky bit. It is almost like OO programming paradigm: the
"types" are limited to genes/ chromosomes/ genomes/ individuals/
populations, the objects are limited to actual genes/ genomes etc and
the operators are all like methods.  We could have a way of specifying
in which order all the operators should be applied - but I am sure it
would require the complete theory of this "programming paradigm.
I am sure it would make a quite interesting research project - but for
now I think we should concentrate only on the first - structural
aspects.

What do you think?  Feel free to reuse/modify this text.


best regards
Mariusz

Re: [eaml-design] Initial focus

[Andreas R. <aru...@ac...>]

On Mon, 18 Feb 2002 10:22:43 +1300
"Mariusz Nowostawski" <ma...@ma...> wrote:

> *) what is the basic elementary building block of the individual
> genome? (single gene, single chromosome or a whole genome?)
> 
> I think the user should be free to specify it on a arbitrary
> level. E.g.
> - the genome is one chromosome which is a list of binary genes
> - the genome is two chromosomes one of which is a list of genes with
> integer numbers and the second is a list of genes with an alphabet
> consisting of symbols  [A, B, C, D].
> - the genome is one chromosome which is a tree-like structure
> etc.

Case 2 is the 'most general' one. The others are just special cases.
My prososal for the structure of an individual:

- One individual contains one chromosome set (the genome).
- The chromosome set contains an arbitrary number of chromosomes.
- Each chromosome has a particular type, e.g. binary string, single
int number, an alphabet of symbols, a matrix, a tree structure ...
 
> We can have operators operating on: gene, chromosome, genome, and
> group of individuals. Do we inline the operators into the genetic
> structure description? Or do we "link" them externally?

Operators should be linked externally. In general we have three levels
of operators.

- first : operators working on chromosomes (i.e. recombination, mutation)
  each of these operators is valid for one particular chromosome type,
  for instance an operator which does a mutation of a bit string. The same
  is valid for recombination. We can mate two chromosomes containing integer
  numbers, but an integer number recombined with a tree structure does not
  make any sense.
- second level : operators working on individuals. They require access to
  the whole set of chromosomes and alter individual attributes. An example
  would be the evaluation and the assignment of a valid fitness or score.
- third level : operators working on collections of individuals. They
  could provide functionality like adding a collection to a population or
  migrating individuals between populations.
 
> This is the tricky bit. It is almost like OO programming paradigm: the
> "types" are limited to genes/ chromosomes/ genomes/ individuals/
> populations, the objects are limited to actual genes/ genomes etc and
> the operators are all like methods.  We could have a way of specifying
> in which order all the operators should be applied - but I am sure it
> would require the complete theory of this "programming paradigm.
> I am sure it would make a quite interesting research project - but for
> now I think we should concentrate only on the first - structural
> aspects.

See above. Only third level operators can be linked together to form
an algorithm. It is up to the user to ensure that the link structure
makes sense. Such a model would provide the highest flexibility possible,
for the cost of simplicity.


Andreas


-- 
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+ Andreas Rummler                                                              +
+ Technical University of Ilmenau, Germany                                     +
+ Department Of Microelectronic Circuits And Systems            (__)           +
+                                                               (oo)           +
+ MAIL: mailto:aru...@ac...                                  \/-------\    +
+ MAIL: mailto:and...@in...          ||     | \   +
+ WEB : http://www.inf-technik.tu-ilmenau.de/~rummler             ||----||  *  +
+ PGP : http://www.inf-technik.tu-ilmenau.de/~rummler/public.pgp  ~~    ~~     +
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

"Programming today is a race between software engineers striving to build bigger
 and better idiot-proof programs and the universe trying to produce bigger and
 better idiots. So far, the universe is winning."  Richard Cook

Re: [eaml-design] Initial focus

[<rsi...@pl...>]

----- Original Message -----
From: Mariusz Nowostawski <ma...@ma...>
To: <eam...@li...>
Sent: Sunday, February 17, 2002 10:22 PM
Subject: [eaml-design] Initial focus


> Hi,
>
> Thanks a lot Remon for your document.
>
> Lets use plain text for discussions and LaTeX for the documents.
> We can generate HTML from LaTeX and make it available on the EAML
> web page at some stage.

OK.


> I have discussed some of the EAML aspects with Grant Dick, which
> I will summarize below.  Me and Grant are working in the same
> department in the area of evolutionary computation.
>
> There are quite a number of  aspects to EAML. As Remon said, the
> separation of structure (template) from the actual parameter values is
> an important one.

But before we delve into that, we need agreement on how EAML will/should be
used. In my previous post, I outlined my view on the process of conducting
EA experiments, and EAML's role in it, but I haven't received any comments
so far. The way we're gonna use EAML dictates what is looks like, so I
really feel that we should tackle this issue first.

Re: [eaml-design] Initial focus

[Mariusz N. <ma...@ma...>]

R=E9mon Sinnema wrote:
[...]
> But before we delve into that, we need agreement on how EAML will/shoul=
d be
> used. In my previous post, I outlined my view on the process of conduct=
ing
> EA experiments, and EAML's role in it, but I haven't received any comme=
nts
> so far. The way we're gonna use EAML dictates what is looks like, so I
> really feel that we should tackle this issue first.

Sure. I think EAML should be as self-contained and as flexible as we can=20
make it. I agree with all the points you have said about the separation=20
of inputs and usage pattern for EAML.
However our own pragmatic perspective on EAML is not as much=20
"experiment" driven - it is more "communication" driven. I agree that=20
the idea of treating and describing EA in terms of conducting an=20
experiment is good - but for us it is "too big". We do not really need=20
that much of machinery.

Thus I think it may be bettar to start from something simple, and build=20
on top of it. The design of EAML will evolve, and there is a lot of=20
problems to try to design it once and for all.

What our research lab currently looking for, and what we want EAML to be=20
used for, is:
* to share structural design of the genetic material between frameworks
* to share actual individuals between frameworks

* to be able to instantiate (and parametrize) the distributed EA in=20
multiple platforms (and multiple frameworks)
* to be able to save the state of EA from one framework and=20
re-instantiate it in anothor framework

* other

I think that the spectrum of all possible "experiments" in EA is too=20
broad for us to capture and generalize now. But, it would be interesting=20
project, no doubt.

So, in summary, our view, at least in a short-term goals, is to use EAML=20
primarily as an "interchange" language. But I think all other uses,=20
including the "documentary" aspect, are ok as well.

What do others think?

Mariusz