Code center > Suggestions

Subfunctions

<< < (2/5) > >>

shvarz:
Uhm, this is way over my head, talk to PY or someone :)

I'm a little concerned that if a program works through some loops and jumps then a lot more mutants will become dead.  Any insertion/deletion would mess up the whole thing.  I think the reason why DBs code is so mutable is because it exists in small chunks that are independent from each other.  Mutate one - others still work fine.  But then again I am not a programmer, so I may well be wrong.

Greven:
Num I think we need a new thread on the goto/jump/call/etc. issue!

Greven:

--- Quote ---I'm a little concerned that if a program works through some loops and jumps then a lot more mutants will become dead. Any insertion/deletion would mess up the whole thing. I think the reason why DBs code is so mutable is because it exists in small chunks that are independent from each other. Mutate one - others still work fine. But then again I am not a programmer, so I may well be wrong.
--- End quote ---

I understand you concern shvarz, but I think it should be evolutions job to select against this, but I think we need to discuss this to make the syntax as easy as possible, so it wouldnt be to difficult for evo to evolve this!

Numsgil:

--- Quote ---
--- Quote ---I'm a little concerned that if a program works through some loops and jumps then a lot more mutants will become dead. Any insertion/deletion would mess up the whole thing. I think the reason why DBs code is so mutable is because it exists in small chunks that are independent from each other. Mutate one - others still work fine. But then again I am not a programmer, so I may well be wrong.
--- End quote ---

I understand you concern shvarz, but I think it should be evolutions job to select against this, but I think we need to discuss this to make the syntax as easy as possible, so it wouldnt be to difficult for evo to evolve this!
--- End quote ---
I agree, if the bot mutates such that it never reachest the end of its DNA, it will die.  But there are lots of mutations that are lethal.  The trick is just to reproduce at low energy amounts, so the vested energy in each kid is low.

Subfunctions could probably take values from the stack, making them a custom command.  Then the other commands, the more complex ones, can be made into subfunctions that themselves are capable of being mutated, and will also cost the bot energy based on complexity.   (A ceil uses much less advanced commands than a pyth, so it would make less nested subfunction calls).  The only problem is in mutating new commands, and representing the new commands somehow.

Carlo:
I agree with Shvarz. There's no need to add to the language things which you can already obtain with the actual language. A few points to remember you WHY the actual language works the way it works:

1) the activation condition/ body model resembles vaguely that of dna. It is believed that the genome works as a giant network of reciprocally influencing genes; many alife simulations use neural or similar networks as a dna; the DB language is not much different, in that it allows you to design networks of genes activations. The advantage of the DB language over networks is that you can directly program a DNA, and that you can understand (with some effort) how a mutated DNA works.

2) the dna language has been designed to have a syntax reduced to the bone. This is because dnas are going to be randomly mutated, and a random mutation which breaks the code's syntax is just a waste of time. So, the syntax is very very simple, the only requirement is to preserve the cond start stop structure and to put comparison operators and commands in their respective place (that is, in the cond part and in the body part, respectively). There are no other rules.

3) the dna language has been designed to ensure a fair distribution of computational time between robots. The alife simulators allowing a traditional language, Tierra and Avida (I.e., they allow loops and subroutines) solve the problem of the distribution of cpu resources allowing each organism to execute only a precise number of _single instructions_ per cycle. The DB language allows the execution of the entire dna. You can have loops, but you have to split them in different cycles.

4) the resulting language is Turing-complete, in the sense that you can express with it whatever you can express with every other, more complex, language.


So, I perfectly agree with Shvarz. You can already do everything in the current language and whatever you may add to it will make it more difficult to mutate and decrease its evolvability. As for the subroutines (without cycles of any kind): they may be comfortable, but there's nothing you can't do with the actual system. Subroutines would create new problems, because they would break the linearity of the dna execution. They would be substantially macros, separated from the rest of the dna. Why don't you write an external compiler instead? Write a standalone program which receives as input a program in a more "comfortable" version of the DB language and produces a dna as an output. Could be very interesting from the point of view of programming combat bots.

Some other considerations:

I'd agree on making the syntax even looser by allowing to mix cond, start and stop everywhere in the code, as well as allowing the use of comparison operators and instructions everywhere. But this would be, after all, a minor change (and it would make the code much much more difficult to read).

I don't understand why you want so much to have junk dna. JUnk dna is dna which is not used and has no use. Being not used, it will become a total junk and will never by usable again thanks to a mutation. So its size will always increase, never decrease, and will never be useful to evolution. So tell me why you want junk dna so much (leaving apart the fact that there's already junk dna).

Navigation

[0] Message Index

[#] Next page

[*] Previous page