Code center > Suggestions

Codules

(1/7) > >>

Numsgil:
I've been working on this and I think it solves alot of problems.  Really one of my better ideas.

Each Bot will have various "Codules" which are short code snipets (or long code snipets, length is irrelevant) that are all assigned to certain numbers.

A basic bot might have 1000 codule "slots" in a codule array.  Custom bots could increase or decrease that number.

During DNA execution, say you have something like:

50 goto

Codule 50 will be executed.

Here are the basic featues/points:
* Empty codules will have (some random slot in the codule array) goto.  So if a bot mutates a goto statement and there's only one codule, the bot will execute that lone codule.  I imagine the best way to do this is to "shuffle" the codules.  That is, say you have an array of 5 codule slots.  The slots would call each other creating a circuit.  Like this:

1->5->3->4->2->1

This ensures that given a goto command that doesn't actually point to an existing codule:

1.  Something happens, and so the mutation isn't quite so hit-or-miss.
2.  Points to the same codule every cycle until a new codule is added or the codule it points to is deleted.  For instance, if the DNA calls codule 1 and 2 is the only codule with code in it, 1 will goto 2.

Now suppose the bot mutates and acquires a codule at 3.  1 now points at 3.
3.  The chances of where a random codule points is more or less evenly divided among the existing codules.
* Codules that are called have their index placed on a "calling stack".
* When a codule is called, a check is made to see if that codule's index is already on the calling stack.  If it is, the codule doesn't execute.  Or we could have it execute so long as there's less than a fixed number in the stack.  The idea is to prevent infinite loops.  Any finite upper limit will stop infinite loops, so the number can be anything.

I'm thinking having an upper limit of 100 instances of a Codule on the calling stack is a good value.  That allows some fairly complex recursive functions that can't hang the system.
* When a codule finishes executing, it pops the calling stack (removes its instance from the stack) and returns to where the goto that called it ends.
* Once a goto is encountered, flow moves to the codule pointed to by the top of the regular integer stack.  This means you can construct goto's that call different functions based on the value of a single sysvar.
* Values can be passed to and from codules through the stack since the goto statement basically just moves where the program is executing and doesn't change any scope or anything like that.  You could therefore sort of code your own custom math operators and things like that.
* Codules can be passed between bots as viruses (either in shot or tie form).  An incoming codule replaces whatever codule was in that slot previously.  In fact, this is what I'm thinking should replace the present virus system.  The effect would be that viruses would be far more intimately connected with their host, and trans-species transmission wouldn't be a real problem to worry about (infected bots would just accumulate the new codule as "junk".  It would only execute the codule if the codule happened to replace an active codule slot, or the bot mutated to active the codule).
* Codules are immune to flow controls from the gene that called it, and the gene that called it is immune to flow controls from inside the codule.  Say the DNA looked like this:

start
1 goto
1 .up store
stop

Codule 1:
stop

Calling codule 1 won't prevent the 1 .up store from executing.

This helps encapsulate possible mutations.  Mutations can't cause direct changes in program flow for any DNA that calls them.There are two things I'm uncertain about:

1.  Should bots' regular DNA be represented as a Codule, perhaps with a "root" index of 0 or something like that.  If so, all bots' DNA would be highly susceptible to viruses since the "root" DNA is responsible for everything that defines a bot.  On the other hand, a bot would be able to call it's root program setting up some recursive possibilities.  Maybe root DNA can be accessed from inside the bot but can't be replaced by a virus.

2.  Should bots be allowed to actively modify its codules?  This goes into self-modifying DNA code, which is a whole other can of worms really.  A bot that could write it's own DNA on the fly could be quite adaptable and powerful.

The basic effects that it simulates:
1.  The Swtich-Case statement in other languages.  You just would set up something like:

cond
*.robage 5 <
start
*.robage goto
stop

to set up a multibot.  You'd just put codules in the first 5 slots that correspond to the first 5 steps of your multibot.

2.  Program Hierarchy - It simulates the effect plus some of the "Noble Genes" I talked about last summer.  Also, this allows for a more structured approach to building Multibots, since you can create a run a kind of state tree that is reflected in the coding architecture.

That is, mutations are more likely to respect the basic structure of your DNA, and so are more likely to stay in line with your original DNA's purpose (I imagine).

3.  It encorporates a new virus system that addresses many (if not all) the issues shvarz pointed out with biological equivelances.

I'm sorry if any of the above is a little too comuter-ese, I'm writing this write before I go to bed and I'm always a little less comprehensible when my brain shuts down ;)

Elite:
Wow, great idea.

Self-modifying DNA - why not? That would make for some super-cool bots. Lots of new oppertunities

Mmm ... new virus system ...

 :drool:

EricL:
Very nice.  Some quick feedback:

I'm all for enhancing the regulatory and structural elements of the DB DNA language.  Codules would be hunks of semi-atomic structural information whose expression could now be more richly controlled.  I think the term "Transcription Factor" is the biological equivalent.  They become a unit of mutation, sequence exchange and expression.  Genes are the expression triggers.  Love it.

This question of what language mechanisms to use is a hot area of research in the ALife community.  If I understand it correctly, the propsoal is not unlike elements of the transsys language which is a "formal language for modelling regulatory network systems conssisting of transcription factors and genes encoding them." See: transsys overview

From what I have read, it seems that much of the evolution of complex organisms is about selection for regulatory elements, not just structural elements.  That is, it's not just about evolving better genes that do better things, is about evolving better logic about which and when what genes are expressed I.e. evolving a regulatory system which expresses the right genes at the right times in the right way.  Evolving better transcriptions on your own takes time.  It's faster for selection to operate on the regulatory system governing the expression of already evolved DNA sequences (whcih you may have stolen from different species).

Did you know the length of the genomes of different biological organisms are not necessarily corrolated with pheneotype complexity?  I didn't.  Some "simple" species like some newts for example have genomes a lot longer than humans.  Most of the "code" never gets expressed in a given species yet it is preserved accross generations in case futue selection pressure selects the regulatory system to express it, in effect, selecting for expression of dormant codules.   Lots of genes (or is the right term 'transcription factors'?) are very old, having changed little over time.  They evolved long ago in common ancestors of today's different species.  They are just not necessarily expressed or expressed in the same way in different species.  So, I'm all for adding a richer mechanism which allows for selection to operate more richly on the regulatory system.

That said, I have to noddle on the implementation specifics.   Some quick thoughts:

I like the linked list of current codules and that gotos are indexes into that list.

I like that newly aquired codules get inserted at end of the list.  You don't want the aquisition of a new codule to necessarily screw up the expression logic for current codules.  Aquiring a new codule (though mutation, gene exchange, sex, virus, etc) should be a separate thing from a mutation which starts expressing that codule.

I think you want codules to be able to be expressed multiple times per cycle.  I don't understand the infinite loop risk.  I assume codules cannot invoke genes and that there are no looping primities in the DNA language.  Thus there must be one goto for each codule expression, right?.  Where do you get loops?

I assume use of codules would not be mandated.  Current bots which emodied all their DNA in genes would continue to work.  Thus, the tradoffs about whether an organism puts their DNA in codules or genes and the resulting advatnages and disadvantages of each strategy such as susceptability to things like viruses can be left up to the bots and their authors.  I.e. I feel no need to create special cases such as "root" codules that are immune to viruses.
 
Isn't self-modification of DNA is a separate issue from the codule issue, the pros and cons of which can be disucssed as a separate topic?

-E

Numsgil:

--- Quote ---I think you want codules to be able to be expressed multiple times per cycle.  I don't understand the infinite loop risk.  I assume codules cannot invoke genes and that there are no looping primities in the DNA language.  Thus there must be one goto for each codule expression, right?.  Where do you get loops?
--- End quote ---
It's not that codules can't be expressed multiple times per cycle.  It's that codules can't (or should be able to only a limited number of times) call themselves or another codule that calls themselves.

For instance, say Codule 2 calls codule 5.  Now Codule 5 calls codule 2.  This creates a potentially infinite recursive loop that the program would have a hard time detecting.  By limiting the number of instances that a codule can have on the calling stack, after a certain point the above goto calls would fizzle and not do anything, at which point the codule would pop from the stack and return control to the previous codule, which would pop, etc.

You have to be really careful about infinite loops in a project like Darwinbots.  Other ALife sims that use organism code generally have robots (or whatever) all executing their DNA one command at a time every cycle.  Bots with infinite loops are permissable and even encouraged as they only effect themselves.


--- Quote ---Isn't self-modification of DNA is a separate issue from the codule issue, the pros and cons of which can be disucssed as a separate topic?
--- End quote ---
Yes, but it seemed to come to mind as I was playing with this idea.  If you'd like to talk about it too, we can start another topic.

-E

EricL:
Okay.  Codules calling codules.  Got it.

We need a natural backpressure mechanism on loops.  What if we thought of infinite loops (and other ineffecient DNA execution aberations) as a form of cancer?  Assume a goto costs something.  If the engine calculated energy usage periodically during the genome execution, say at every goto, there would be tremendous selection pressure against infinite loops and other gross regulatroy ineffeciences.  As long as the stack was large enough, a bot which mutated an infinite loop would die that cycle without any artificial limits on codule executions per cycle.  That said, a sufficiently high limit as a simulator safeguard - one that no organism without cancer would ever hit - would certainly be advisable.

Navigation

[0] Message Index

[#] Next page