IRL DNA

[jknilinux]

Will it be possible to make DNA where, no matter what the sequence is, it WILL do something? See Jot . I quote from the website

"Every combination of 0's and 1's is a syntactically valid Jot program"

I think this would simulate DNA MUCHH better than our current "Magic string" system, where only a select few magic strings of DNA actually do something. It would be a nightmare to try and see what a 500bp jot program does, but I think it would be perfect for evosims. For example, in IRL DNA any string of ACTGs produces a protein, no matter what. I'm pretty sure Jot can also self-modify.

So, how hard would it be to implement this language as an option? Would making a de-obfuscator/assembler be possible?

[Numsgil]

Actually this is something I did for DB2 in version 2.4, and DB3 inherits this legacy.  Every sequence of base pairs is syntactically valid and will do something.  Though without a store statement somewhere it'll mostly just push and pop values from the stack without changing a bot's behavior.  Compare this with pre 2.4 DNA or something like C, where if you permute a valid program you do not necessarily get a valid program.

This is important for mutations.  Before, the mutations had a high level understanding of DNA.  Mutations added and removed entire conditions and statements, and the gene structure was rigidly enforced.  Now, mutations can be entirely stupid about how DNA actually works.  They just add and remove, and reorder, and duplicate, etc. "beads" from a string of beads.

[Peter]

Will DB3 still be able to run DB2 kind of DNA.

I'm not talking about if the behavior is the same. Just that it does something, and not crashes.

[Numsgil]

DB3 won't crash.  But the syntax isn't compatible so it'll give a "compile error" when you try to load the DNA.  Sysvars might be named something different so it'll give you other compile errors along these lines, too.

[jknilinux]

Actually this is something I did for DB2 in version 2.4, and DB3 inherits this legacy.  Every sequence of base pairs is syntactically valid and will do something.  Though without a store statement somewhere it'll mostly just push and pop values from the stack without changing a bot's behavior.  Compare this with pre 2.4 DNA or something like C, where if you permute a valid program you do not necessarily get a valid program.

This is important for mutations.  Before, the mutations had a high level understanding of DNA.  Mutations added and removed entire conditions and statements, and the gene structure was rigidly enforced.  Now, mutations can be entirely stupid about how DNA actually works.  They just add and remove, and reorder, and duplicate, etc. "beads" from a string of beads.

DB3 can modify the DNA inside codules too, right? How do you imagine zerobots to evolve with codules?

[Numsgil]

Self modification is something I'd like to stay away from.  I think it would tend to cause more harm than good.  Although I do plan to allow bots to modify the mutation rates of codules, or force a mutation, if they want (to model something like what happens when antibodies are being created.  Though I don't think mutations are necessarily involved there).

Codules, like sysvars, have numbers assigned to them.  "Null" codules fall through to codules beneath them (or are randomly connected, I haven't decided.  As long as it forms a long loop it doesn't really matter).  Once the first non null codule is found it executes, maybe calls other codules, then exits and the call stack collapses back up the tree.  Or if no codules are non null eventually it'll try to call a codule already in the call stack, fizzle, and then the call stack will collapse back up.  I might also designate some subset of the codule space for "sub codules" which can only be called from a "parent codule".

So basically a zero bot might evolve a call to codule, say, 172.  At first this does nothing.  But then maybe there's a mutation which snips off a piece of the main DNA thread and assigns it to codule 14.  That call to codule 172 will end up calling codule 14 and that snippet of code will execute.  If another codule gets created at, say, 50, that one will execute instead.  So it should be pretty easy for evolution to evolve some codule usage.

[jknilinux]

Self modification is something I'd like to stay away from.  I think it would tend to cause more harm than good.  Although I do plan to allow bots to modify the mutation rates of codules, or force a mutation, if they want (to model something like what happens when antibodies are being created.  Though I don't think mutations are necessarily involved there).

-So they can't modify that which is in codules? Only change mutation rates? How, exactly, does evolution view DB3 DNA?  How would it switch, for example, 2 DNA strands in the same codule?

So basically a zero bot might evolve a call to codule, say, 172.  At first this does nothing.  But then maybe there's a mutation which snips off a piece of the main DNA thread and assigns it to codule 14.  That call to codule 172 will end up calling codule 14 and that snippet of code will execute.  If another codule gets created at, say, 50, that one will execute instead.  So it should be pretty easy for evolution to evolve some codule usage.

-What is the main DNA thread? Is there some sort of main non-codule thread that always executes, and then codules are just interrupt-driven data structures?

[Numsgil]

Self modification is something I'd like to stay away from.  I think it would tend to cause more harm than good.  Although I do plan to allow bots to modify the mutation rates of codules, or force a mutation, if they want (to model something like what happens when antibodies are being created.  Though I don't think mutations are necessarily involved there).

-So they can't modify that which is in codules? Only change mutation rates? How, exactly, does evolution view DB3 DNA?  How would it switch, for example, 2 DNA strands in the same codule?

What do you mean by two DNA strains in the same codule?

So basically a zero bot might evolve a call to codule, say, 172.  At first this does nothing.  But then maybe there's a mutation which snips off a piece of the main DNA thread and assigns it to codule 14.  That call to codule 172 will end up calling codule 14 and that snippet of code will execute.  If another codule gets created at, say, 50, that one will execute instead.  So it should be pretty easy for evolution to evolve some codule usage.

-What is the main DNA thread? Is there some sort of main non-codule thread that always executes, and then codules are just interrupt-driven data structures?

I'm not sure what you mean by interrupt driven data structures.  Imagine that current DB2 DNA.  It's like a "main" codule.  It gets called once per cycle.  From that main codule you can call other codules, like function calls in a C program.  The difference is that if you attempt to call a codule already on the call stack it just fizzles.  And if you attempt to call a non existent function it calls the "closest" function it knows about.  The main codules is probably codule 0 (so that "null" pointers play nice and fizzle).

The codules themselves behave exactly like the main codule.  There's no extra magic behind the scenes.

[jknilinux]

I guess I'm asking: how does evolution only work on codules and not on DNA commands? Or, like you said, on "beads" and not on the DB assembly itself? That's the goal with codules, right? How is that the same/different?

Also, I was asking what the difference is between the main codule and the others... is it just that the DNA execution begins in the main codule? So is the main codule kinda like the int main(argv, char* argc) function in C?

[Numsgil]

The beads in my analogy are individual base pairs (add, store, etc.).  Though mutations can work on the codule level as well.  So codules can be duplicated, deleted, randomly inserted, etc.  But most of the "work" of evolution will be inside the codules doing traditional mutations.

Yes, the main codule is like the int main in C.

I might also create some "system" codules, that are called specially for certain events.  They'd operate sort of like a callback.  For eyes, for instance, I'm thinking that each object visible to the bot causes a special "vision" codule to fire.  Each call of the vision codule would happen by the system, and would change the sysvars sent to the vision codule.  After the vision codule has been fired for each visible object, the main codule gets to run.  To keep with the C analogy, these system codules are sort of like interrupts.  I still have to really think through the implications, but it makes a lot of sense to me right now.  The only real downside is that it hard codes some really high level structure to the DNA.  I'd be happier if the DNA didn't require imposed high level structure.  But I can't think of a nice way to do something like:

Code: [Select]

given visible objects, sort based on distance
for each visible object in sorted list
call appropriate reaction codule
with my current plans for DNA.  The main problem is the foreach type loop.  I really don't want to expose looping capability to the DNA, not even finite loops where there's definitely a finite number of iterations.  It's far too easy for evolution to invent some sort of nest loop that would eat through performance.  If you had 3 loops from 1 to 1000, nested in side each other to form a trivial O(n^3) algorithm, it'll take about 3-5 seconds to run per bot per cycle.  With the way the DNA currently works, even with plans for Codules, there's a direct link between DNA size and execution time.

I could make it a language rule that loops can't be nested (have nested loops fizzle), but that seems overly arbitrary.  And it would make debugging DNA potentially confusing since the rule would have to be enforced across codule boundaries.

[ikke]

Code: [Select]

given visible objects, sort based on distance
for each visible object in sorted list
call appropriate reaction codule

Not within a single cycle, but I think it is realistic that a bot stores info for an object it focus in its memory, and then shifts focus. It can then compare by traditional means things it deems relevant. For instance: you say you want to sort by distance, but what if I want to sort by threat level based on refkills, or distance over relative speed?
There are two main differences:
1) in this solution it takes more cycles to assess al objects and
2) the number of objects assessed / parameters stored is not open ended but predetermined by DNA.
I think both properties are as they should be

[Numsgil]

Code: [Select]

given visible objects, sort based on distance
 for each visible object in sorted list
 call appropriate reaction codule

Not within a single cycle, but I think it is realistic that a bot stores info for an object it focus in its memory, and then shifts focus. It can then compare by traditional means things it deems relevant. For instance: you say you want to sort by distance, but what if I want to sort by threat level based on refkills, or distance over relative speed?
There are two main differences:
1) in this solution it takes more cycles to assess al objects and
2) the number of objects assessed / parameters stored is not open ended but predetermined by DNA.
I think both properties are as they should be

The problem is that I'm working to make vision work using apparent magnitude.  So you can potentially see infinitely far away if the object you're looking at is infinitely big (or if it's an infinitely sized cluster of smaller objects, like a veggie colony).  See vision.

Which means that the number of things to cycle through in your vision is potentially quite large.  You are right about maybe wanting to sort across different criteria, though.  Another option is to not sort it at all, and run the codule simultaneously for each visible object.  Then the problem becomes how to sort between conflicting information.