Author Topic: A bunch of suggestions  (Read 3709 times)

Offline MacadamiaNuts

  • Bot Destroyer
  • ***
  • Posts: 273
    • View Profile
A bunch of suggestions
« on: January 05, 2007, 06:30:04 PM »
Hi.

I've been messing around with DB for quite some time and decided to register and post some suggestions.

1. Bots doesn't like much to evolve complex genes... they trash them before they do anything useful. Could you add single commands to create the first four ties, if they aren't present, and set both tieloc and tieval picking the last two stack numbers? So this:

1 .tienum store
-1 .tieloc store
x .tieval store

Would look like this:

-1 x tie1 store

It checks if there's already any tie with tienum 1 and, if not, it creates it. Also it sets tieval and tieloc.

2. I would like an option to disable mutations of flow commands, so they won't be deleted, replaced or added. Whole genes may be deleted or added with zero filled conditions and commands. Then a working sexrepro that picks genes one by one from parents.

3. Also, an option to mutate conditions and commands from a pool of patterns instead of randomly. *# # > would be a condition pattern, with numbers added on the fly. Evolution would happen faster since they don't need to wait until they get some functional code from a pile of junk, and yet there are large chances that the resulting gene won't be useful. Also it will be readable (nice for non uber DB users that can't read through a pile of nested conditions, sysvars and binary operators).

4. Fitness culling with customizable targets. For example, each 500 cycles kill the 10% bots with less kills.

5. .membrane and .enzyms sysvars, transferred (and maybe mutated) at birth. Any value added to these is modded to -1, 0 or +1 so changing the membrane and enzyms properties would happen slowly. The closer the bot's enzyms are to the target's membrane type, the more efficient it is capturing energy/body through shots or ties. So a bot can use dumb-veg eating enzyms (type 0) and use a different membrane type so shots/ties from other veg eater bots (even their own species) wont digest it by mistake. Or maybe it can develop enzyms to eat the veg eaters, even if those enzyms aren't worth anymore to eat vegetables...

Also, in pond mode, a PH option meaning membranes that don't match the PH at certain level will lose energy. Corpses would have the opposite membrane value than 0 vegetables, so vegetables may use their own shots or ties to take waste from corpses.
« Last Edit: January 05, 2007, 08:59:13 PM by MacadamiaNuts »
Sometimes you win, and sometimes you lose...

Offline MacadamiaNuts

  • Bot Destroyer
  • ***
  • Posts: 273
    • View Profile
A bunch of suggestions
« Reply #1 on: January 05, 2007, 09:38:38 PM »
Oh, just something more about ties:

When tied, storing anything at .sync would make that bot to use the movement sysvars in reference to the aim of the bot that stores anything at a .follow sysvar.

So when a synced bot stores something at .up, it will move towards the aim of the bot that last called the .follow.

I tried once to do this sending mem values through ties and through .out values, but since tied bots couldn't turn much to match the aim of the bot telling them to follow him it didn't work very well.
« Last Edit: January 05, 2007, 09:42:18 PM by MacadamiaNuts »
Sometimes you win, and sometimes you lose...

Offline Jez

  • Bot Overlord
  • ****
  • Posts: 788
    • View Profile
A bunch of suggestions
« Reply #2 on: January 06, 2007, 01:24:27 PM »
If you haven't read it already then Shvarz started a topic genome structure to discuss ways of changing the dna structure to improve the evolution of genes.  
If you try and take a cat apart to see how it works, the first thing you have in your hands is a non-working cat.
Douglas Adams

Offline shvarz

  • Bot God
  • *****
  • Posts: 1341
    • View Profile
A bunch of suggestions
« Reply #3 on: January 07, 2007, 03:04:08 PM »
I like the idea of having some "basic structures" that would get inserted by mutations.  We don't have to limit insertions to such structures, but they would be a nice addition.
"Never underestimate the power of stupid things in big numbers" - Serious Sam

Offline EricL

  • Administrator
  • Bot God
  • *****
  • Posts: 2266
    • View Profile
A bunch of suggestions
« Reply #4 on: January 07, 2007, 05:23:25 PM »
1) I understand the lure of trying to pack higher level logic that today is only expressable via a longer sequence of base pairs into shorter base pair sequences so that interesting DNA sequences are more mutation resistant and more likely to remain intact when moved around via mutations.  There may be places where we should do this for consistency or expressivness sake, but IMHO, it is a false hope.  There will always be interesting logic that can only be expressed through a sequence of base pairs long enough to be fragile.  What we need is a way for base pair sequences to evolve to become evolutionarly stable.  

I am working on a proposal for decorating DNA with locality relative mutation probability tags which would allow selection to influence the probability of a mutation occuring within some bp sequence, where it occurs within the sequence and the size of the BP sequence impacted.  The tags would be part of the DNA and be mutable.  Thus, a bp sequence (such as a gene) could aquire (would be selected for) its own set of mutation probabilities which impact the entire sequence and thus it's probability of say, being duplicated as a whole in a copy mutation.

I have some more work to do before this is thought through enough to post, but done right, this would allow evolution to favor copy mutations falling primarily along gene boundaries or longer sequences such as gene family boundares or along short sequence boundares such as X .Y store triplets such that base pair sequence structure would be preserved in certain kinds of mutations.  This I think is the long term answer to evolving complex DNA structure that is stable in the face of mutations.

2) I think the proper way to provide for mutations respecting genomic structure is to allow for selection to evolve what strucutre is important and to influence the probabilities of mutations breaking that structure through loci-relative mutation probabilities as I describe above.  Thus, I think I am opposed to adding special hard coded logic which treats flow commands differently from other BPs w.r.t. mutations or which attempts to force conditional gene structure on the genome by artificially respecting gene boundaries.

I am not oppsed to providing base mechanisms that operate on and respect gene boundaries as a means for facilitiating  horizontal gene transfer with an eye towards provides the means for sexual recombination operating on gene boundaries.  Afterall, viruses respect gene boundaries today and I view it as bootstrapping DNA reading logic.  But I think I am opposed to emboding any explicit recombination logic in the simulator itself.  As I have discussed elsewhere, I would prefer to see sex and recombination strategies evolve, not be dictated by the simulator.

3) As described in #1, that is the approach I favor w.r.t. preserving sequence structure in mutations.

4) I like this idea.  Probably should be done as part of a larger scripting effort.  

5) Membranes...Sounds cool.  Not something I'm going to implement tomorrow, but I generally favor things which increase the potential morphological complexity.

6) .sync .follow...   I think I am opposed to special casing operations such as movement sysvars based upon the state of other bots.  There are order of operation pitfalls in the implementation for one thing and on a philosophical note, we have to be careful about maintaining distributed independence.  I'm all for letting bot A know things in a non transitive manner about bot B, but I think I am opposed to implicitly changing any of bot A's state or operations (other than purly informational state such as refvars) based upon bot B's state.
« Last Edit: January 07, 2007, 05:34:21 PM by EricL »
Many beers....

Offline Numsgil

  • Administrator
  • Bot God
  • *****
  • Posts: 7742
    • View Profile
A bunch of suggestions
« Reply #5 on: January 07, 2007, 07:59:03 PM »
About membranes and things...  The question is wether we want diet specialization to be behavior or physiological.

Imagine a lion and a handful of grass.  Now imagine an ant and an acorn.  In the case of the lion, not eating the grass is a choice.  The lion could eat the grass.  It probably would result in either a case of the runs, terrible gas, or some up chucking.  The ant and the acorn, on the other hand, is a case of physical impossibility.  You aren't going to cram an acorn down any ants I know of.

I think, in dealing with shots, that the case with the lion is the better analogy.  It's not that bots shouldn't be able to shoot, kill, and even attempt to eat other bots.  I think it's that eating something that's "wrong" should result in undigestable matter that needs to be removed.

For the case with the ant, I'd like to see something like phagocytosis going on.  Bots would "swallow" another bot, if the size discrepancy wasn't too bad.

Offline Endy

  • Bot Overlord
  • ****
  • Posts: 852
    • View Profile
A bunch of suggestions
« Reply #6 on: January 08, 2007, 09:32:37 PM »
Soemwhat off topic, but I do distinctly remember cats at home eating grass on ocassion.  

Cats Eating Grass

More on topic:

Wanted to suggest adding in "randr" to give the bots a way to generate random numbers within a range of values. ie.

300 330 randr

would return a random value between 300 and 330. Re-reading some of what Nums wrote elsewhere, got me thinking about how the bots are mainly using their memory array as a source of limited random values for storage locations. Like say, *.eye5 or *.vel both of which are failrly random but limited to a more useful range of values.
« Last Edit: January 08, 2007, 09:41:31 PM by Endy »

Offline MacadamiaNuts

  • Bot Destroyer
  • ***
  • Posts: 273
    • View Profile
A bunch of suggestions
« Reply #7 on: January 09, 2007, 07:44:20 AM »
Oh, you can do that with:

30 rand 300 add
Sometimes you win, and sometimes you lose...