Code center > Suggestions

Disabling bitwise functions

(1/2) > >>

Numsgil:
It seems to me that:

1.  No people have played around with the bitwise functions in the DNA (things like ~, |, &, etc.)

2.  Bots that evolve them are rather difficult to decipher.

How do people feel about getting rid of the bitwise functions in upcoming versions?  Keep in mind that I'm working on a bot debugging tool that would let you step through the DNA of your bot, watching the stack change.

Henk:
as long as they aren't a heavy load on performance I say keep them, especially with a debugger coming.

EricL:
It strikes me as quite natural that the DNA of an organism whose base pairs are stored as 32 bit numbers should be able to express effecient operations on those numbers...

My intuition tells me that there is an inherent problem with a DNA grammer that has with a large number of *opaque* and complex base pairs as opposed to a very small number of simple and fundemental BPs which can be strung together to form higher level operators.  Think CISC v. RISC.   Bitwise operators allow for our base pairs to be thought of as essentially marcos of the underlying base 2 base pairs.  I think we want to retain this.  I do not think we want our high level 32-bit base pairs to be opaque to DNA operations.

Additionally, I would someday like to experiment with nerual nets in the DNA.  Evaluating weights will be easier and more effecient with bitwise operations...

Numsgil:
My only real issue with it is that I have a hard time deciphering DNA sometimes that evolves.  A large part of DB is figuring out exactly what's going on in evolution.

Hopefully the bot DNA debugger I'm working on in the C++ version will make this a little easier, but if someone is posting a bot's DNA in text, it still becomes a little difficult to decipher.

Just playing devil's advocate.  I generally like more instead of less.

EricL:
Like biological DNA, I expect that decyphering any but the most trivial evolved DB DNA will always prove to be a challenge independent of the underlying grammer.  Nature loves effeciency and effeciency and human understandability/readability are often at odds, in evolved or designed code.  Some of the earliest ALife simulators showed this not to mention some of my earlist code  

I remember reading about an evolved sorting routine  - in Avida I think - that was almost as good as the very best human designed algrythm.  They had a hard time figuring out how it did what it did and once they had, they were of course amazed in that the approach was quite non-intuitive from a human point of view...

I would say that the grammer should be as simple as possible, but no simplier.  We want the fewest number of base pairs possible which can effecienctly express the richest possible semantics.  If there is an equally effecient and equally evolvable equivalent expression for something than I'm happy to ditch the duplicate...

Navigation

[0] Message Index

[#] Next page