Disabling bitwise functions

[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...

[Endy]

Not sure the dna is efficent or obtuse. Evolution is likely to take the most round-about method imaginable to reach it's solution.

Seems like the stores, inc, dec are the most meaningful parts of the dna.

If the de-bugger could somehow isolate which values are actually stored/inc/dec in the genome it'd be pretty useful.

Alot of what is in the genome really is "junk", mutation correction material, or fodder for new mutations to spring from. While useful to the bot, it doesn't actually do anything so isn't truly vital for us to see.

[PurpleYouko]

Did anyone ever try using the partially complete de-bugger in the Excel Snapshot utility?

It is missing a lot of the bitwise stuff but could very easily be updated to include it.
The program contains a stepping function to move through the genome one command at a time and keeps track of all the values in the stack and all memory locations.
It even gives you the ability to change memory locations at will to see what effect it will have.

[Jez]

Don't delete 'em! I haven't had a chance to fail to use them properly yet...  

From my POV as a returnee, the bots are almost scary in how mathmatically accurate you can make them now, eye5 is old news now having been replaced by (refxpos refypos angle setaim) or (refxpos refypos distance.) (I figure:) There is a way round aimsx/dx now using .aim. All I need to do now is figure out how to avoid using .up, and I shall have a formula of 'botic beauty!

Seriously, instructions that allow you to replicate old instructions like *.eye5 and avoid the previously relevant pitfalls, (like *.refeye, I can't ref .angle or .refxpos) shouldn't be added just to make the maths easier. It's not meant to be a robot simulating a robot (IMO) it's meant to be a bot simulating a life form.

Just to emphasise the inacuracy of bioforms, try poking a small spot at arms length with the tip of your finger really quickly, most of us will miss by a bit most of the time.

   Robots are 100% accurate 100% of the time, bioforms are a bit more hit and miss and need to practice first.

[Numsgil]

Most old ways of doing things should still work.  Primarilly there are just some new ways of doing old things that are a bit more accurate.

Over accuracy is something of an issue.  It doesn't seem to create a problem for the bots as either human machinations or evolving virtual lifeforms, but it certainly strains believability for the bots being analogous to real life forms.

Just changes the combat tactics mostly.  It's difficult to sneak up on an opponent.  It's difficult to hide from a persuer (though Enitor Comesum gives it a pretty good try).  Pretty much all you can do is dogfight your oppenent.

[Numsgil]

edit: Just a quick note, when a bot shoots a shot, there is a little innacuracy in its angle.  A spread of something like +/- 8 or 9 degrees.