Gene structure - cond start stop

[Zinc Avenger]

I've been thinking about the structure of genes.

The cond-start-stop structure is very fragile, practically any mutation in the wrong place will break it completely. It is also prohibitively difficult to evolve naturally - what's the chance a cond instruction will appear before a condition to evaluate, then a start will appear, then an appropriate action will evolve with a stop at the end? Vanishingly small.

So why not simplify it?

Remove cond and start.

Change the way genes are handled so that only stop is used.

Make the stop command define the end of a gene. So from the start of the genome to the first stop is the first gene. From the first stop to the second stop is the second gene. From the last stop to the end of the genome is the last gene. Make no stop at all mean the entire genome is one gene.

But that would not allow us to have conditional genes. So I got to thinking - if the gene is defined by the stop command at the end, why not make the condition the last part of the gene?

The way I envision this working is like this: Fire the gene speculatively, calculating the changes to the memory locations, but don't commit them to the simulation. If the value on top of the stack when stop is reached is greater than zero, commit the results to the sim. If not, discard them.

[Numsgil]

That's pretty close to the way that the DNA works in the DNA module for Darwinbots 3.  Although instead of executing the gene speculatively and then checking the stack for values, the conditions are integrated into the gene.

The problem with using just the integer stack for conditions is when you try to introduce logic commands.  How do you represent true/false?  You could just do 0/1, but that doesn't really make sense.  What does 500 1000 > 30 add mean?  So you really need that second stack (the conditions stack) to keep the language clean.

For DB 3, a simple gene might look like this:

*.nrg 1000 > 50 .repro store

which entirely bypasses the cond-start-stop system.

As far as the current system, the gene structure is actually far more forgiving than people think.  Cond statements set a flag that determines whether start or else blocks are enabled.  A single cond can control lots of genes.  And if there isn't a cond statement anywhere up stream, the program just "assumes" a "true" value for the last cond evaluation.

[EricL]

I think we want to keep the start codon as I think we want genomes to be capable of containing non-coding DNA.  We want a single point mutation such as the addition of a stop or the removal of a start to be able to have large impacts on the geneome, I.e. to be able to turn on or off whole genes, combine genes, split genes in two, etc.  We want junk DNA which can mutate for awhile without selection constraints and then get re-enabled.

That said, I like the idea of doing away with the cond and making it implicit.  I agree it would improve the probability of evolving conditional logic if such logic can be scatterred anywhere through the gene.  I don't think it would be too difficult to implement (he says in the confidence of ignorance) since the boolean stack is seperate from the integer stack.  There might be some sticky order of operations issues.  For example:

start
100 .foo store
*.foo 100 =
stop

Should the conditional logic use the old or the new value of .foo?

But I think we could work that out...

[Numsgil]

You don't need to move the condition to the end of the gene if you use the condition stack, too.  You could have it anywhere in the gene you wanted to.

Laying aside the option of entirely deconstructing the idea of a gene as I've done with DB3 (which wouldn't be too difficult to do), you could have conditions interspersed within the gene.  Something like:

start
*.nrg 1000 >
10 .repro store
*.body 1000 >
stop

[EricL]

I like that.  Saves a second pass through the DNA.  It's a running condition.  Memory operations happen when the top value on the boolean stack is true.  They don't happen when it isn't.  Thus a single gene can  contain multiple conditions and sub functions, only portions of which might get expressed depending upon the running condition logic.  Example:

start
*.eye5 0 >
5 .dn store
*.eye5 10 >
10 .dn store
*.eye5 20 >
15 .dn store
*.eye5 50 >
-1 .shoot store
0 .shoot >
0 .dn store
stop

Note that last couple of lines are a cascading condition.  -1 only gets stored into .shoot if *.eye5 is > 50 and 0 only gets stored into .dn if .shoot is less than 0 which only happens if *.eye5 > 50.  Cool.

[Numsgil]

Yep, I like that too

[Zinc Avenger]

 Anything that makes conditions easy to evolve is a good thing! The current system is too unwieldy.

[shvarz]

BTW, in October 19 issue of Science there are two papers describing unusual genes. In one, genome consists of hundreds of tiny chromosomes and genes are coded as small fragments on different chromosomes. Once in RNA form, these fragments are "stitched" together, forming the final mRNA that is translated. In the other one, genes have their beginning and end swapped. For example, a gene "computer" would be coded as "uter-comp". The resulting RNA is then joined together at its ends (bringing comp and uter together), forming a circle. The circle is then cut in the correct place to generate the correct gene.

Just shows how flexible genetic material can be.

[Peter]

I know some,well most genes are sepparated in junk-dna and 'normal'-dna, (introns, outtrons, is this correct in english)after they are translated to m-rna, the introns(junk-dna) are being spliced from it.

I haven't heard of gene that lies in different chromosomes. There are many strange things that lies in dna. There cannot really be explained why. Atleast not jet

[Numsgil]

The real process is wondrously complex.  All those different stages each allow for some interesting variations from "normal".  By comparison, any DNA schemes for DB look hollow and incomplete.  

[Botsareus]

Sounds nice and all but I have a small problem:

Lets say the robot does .dx .up and .shoot within a single condition, according to the above the code will look:

*.nrg 1000 > 10 .dx store
*.nrg 1000 > 10 .up store
*.nrg 1000 > -1 .shoot store

Would it be easyer to use:

cond
*.nrg 1000 >
start
10 .dx store
10 .up store
-1 .shoot store
stop

?!

[Peter]

Ok, I am not fully understanding the code, how would the following gene work.

(random gene taken from multiply, can't make one up)  

cond
*.eye5 25 >
*.refeye *.myeye !=
*.refshoot *.myshoot !=
*.refpoison *.refshell =>
and
and
and
start
16 .shootval store
-6 .shoot store
stop

And how would a gene work if there is some 'or' in it or something else like it.

[EricL]

Lets say the robot does .dx .up and .shoot within a single condition...

start
*.nrg 1000 >
10 .dx store
10 .up store
-1 .shoot store
stop

Would be sufficient.

[EricL]

Ok, I am not fully understanding the code, how would the following gene work....

start
*.eye5 25 >
*.refeye *.myeye !=
*.refshoot *.myshoot !=
*.refpoison *.refshell =>
and
and
and
16 .shootval store
-6 .shoot store
stop


Think of it this way:  conditionals can now be executed in the body of the gene and memory modifications can now be executed in the conditional portion.  The way I'm planning on doing this, a gene begins at either a Cond or Start and ends at a stop.   Conds or Starts in the middle of genes are ignored.   This means that all existing hand-coded bots will continue to work exactly as they do today without a single change.  Total backwards compatability.  However, the behaviour of evolved bots may change as operations which were previously ignored (boolean operations in the body or memory operations in the conditional header) now execute, for example, changing the value on top of the boolean stack and thus may impact the evolved code in a major way causing logic that used to fire to no longer do so or vice versa.

EDIT:  So, a correction. A Start in the middle of a gene isn't exactly ignored.  It means "AND together all the values on the boolean stack and place the result on the top of the stack."

So, the gene above works just fine as does:

cond
*.eye5 25 >
*.refeye *.myeye !=
*.refshoot *.myshoot !=
*.refpoison *.refshell =>
and
and
and
start
16 .shootval store
-6 .shoot store
stop

as well as:

cond
*.eye5 25 >
*.refeye *.myeye !=
*.refshoot *.myshoot !=
*.refpoison *.refshell =>
start
16 .shootval store
-6 .shoot store
stop

But

start
*.eye5 25 >
*.refeye *.myeye !=
*.refshoot *.myshoot !=
*.refpoison *.refshell =>
16 .shootval store
-6 .shoot store
stop

will not work the same.  The stores to .shootval and .shoot will only be predicated on the result of the last boolean operation (*.refpoison *.refshell =>) not on the logical ANDing of all four.  Thus, you can't just remove all the starts from your code.  Doing so will change the behaviour of any genes with more than a single line conditional.

[EricL]

FYI, I am implementing Phase 1 of this for 2.43q.  Conditional commands encountered in the body portion a gene will no longer be ignored.  Operations which write to memory will be conditional on the value on the top of the boolean stack.  Thus, conditional logic in the body of a gene may cause portions of the gene not to execute.

Phase 2 will involve allowing for memory operations in the conditional portion of the gene and will be implemented later.