Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Topics - PhiNotPi

Pages: [1] 2
Suggestions / Population Control and Energy Management Aren't Intuitive
« on: February 23, 2014, 07:22:31 PM »
Edit: I think I make a better argument in my most recent post.

Original post:

I feel that the current (2.46.02) method of energy management and population control is inadequate and counter-intuitive.  In the past, when repopulating and veggies were the same, the system was simple.  Now, with chloroplasts, it is not as simple.

With chloroplasts, there is no set definition of a "veggy."  Bots with many chloroplasts are more veggy-like, while bots with few veggies are pretty much carnivores.  So, menu options like "40 NRG veggy per cycle" does make any intuitive sense.  Given the variability of light level and chloroplast count, chances are that not a single robot received exactly 40 NRG in that particular cycle.  Also, settings like "maximum number average veggies" don't make sense, as they now involve the number of chloroplasts in the sim.

There are a few functions for population control and energy management:

  • Limiting the flow of nrg into the simulation.  This, in turn, helps to create a competitive environment.
  • Simply limiting the total number of robots, which directly improves simulation speed.

Let's focus on the first function.  It is important to limit the flow of energy into the sim.  I think that focusing on the total number of chloroplasts is not necessarily (as of right now) the best way to do it.  The efficiency of chloroplasts depends on how they are distributed (many chloroplasts in one bot, vs few chloroplasts in many bots).

Here are actual measurements, taken at a size 3 sim set to "40 NRG veggy per cycle."  Here, "avg chlr" is equal to the total number of chloroplasts divided by 16000, since that is what is used to determine the repopulation limits and is what is displayed at the bottom of the screen.  I calculated the total nrg per cycle, to give a good idea of how much energy is entering the sim, as well as the nrg per avg chlr per cycle, to balance for the fact that more chloroplasts generate more energy.
  • 325 bots, 1 chloroplast each, light level 30837: Total of 20 nrg per cycle.  About 985 nrg per avg chlr per cycle.
  • 1 bot, 325 chloroplasts, light level 31996: Total of 7 nrg per cycle.  About 345 nrg per avg chlr per cycle.
  • 32 bots, 1000 chloroplasts each, light level 31820: Total of 512 (but sometimes 544) nrg per cycle. About 256 (sometimes 272) nrg per avg chlr per cycle.
  • 1000 bots, 32 chloroplasts each, light level 28422: Total of 1000 nrg per cycle.  About 500 nrg per avg chlr per cycle.
  • 1 bot, 32000 chloroplasts, light level 31996: Total of 224 nrg per cycle.  About 112 nrg per avg chlr per cycle.
  • 30 bots, 32000 chloroplasts each, light level 31798: Total of 6660 nrg per cycle. About 111 per avg chlr per cycle.

So, I guess my point here is that these settings don't do a good job of describing their effects.  The setting of "40 NRG veggy per cycle" does not describe these end results.

First of all, this setting should be renamed to include chloroplasts in its name, because it does not involve the number of veggies.  Rather, it involves the number of chloroplasts.  It functions as a multiplier on the feeding formula. 

If a bot has a high number of chloroplasts, each bot can receive up to 5x as much nrg per cycle as compared to the setting.  If there are many bots, with the same total number of chloroplasts, then there is a very high efficiency, and the nrg per avg chloroplast is much higher than the setting.  You can see this above.

One thing to point out is that this change in efficiency (as the chloroplasts per bot decreases) is actually pretty major.  Let's say that you start with 1 bot with 32000 chloroplasts.  Then it slowly divides into 1000 bots with 32 chloroplasts.  Now, even though the chloroplast count remains constant, the rate of nrg creation has quadrupled.  There are 1000x more bots to share that energy, so each individual bot gains energy very slowly, but there are also 1000x more bots with the ability reproduce.  This all cancels out in the end, so you actually end up with a rate of reproduction which increases over time.  On this basis, I don't think that the current system does a good job of accomplishing task #2, which is to limit population.

The main problem is that these settings (max number of veggies and NRG per veggy) do not do a good job of telling me how much energy is entering the sim.

Most of this can be alleviated by renaming the settings to something meaningful, like changing "veggy" to "chloroplasts."  This will fix some confusion.

Some of this, I don't really know how we might fix it.

One possibility is changing the chloroplast formula by dividing all feeding rates by the magic number 3.54.  This way, when you enter 40 NRG per veggy per cycle into the text box, then the feeding rates are actually multiplied by 11.3 rather than 40.  That way, when a veggy has 16000 chloroplasts (1 "avg" chloroplast) and 32000 light, then it will actually receive 40 energy per cycle.

A second possibility is the creation of two maximums.  There could be the maximum number of chloroplasts (like currently), as well as the maximum number of repopulating robots.

A third possibility it that we can change the way that we turn the sun off once energy levels are too high.  Rather than toggling the sun completely, we can just lower the feeding rates once nrg is above a certain level.  Completely turning off the sun destroys any advantage to having chloroplasts, but lowering the feeding rates accomplishes the same goals without destroying those advantages.

A fourth possibility is to change the chloroplast formula by dividing all feeding rates by the magic number 26.27.  This way, the "NRG per veggy" setting, multiplied by the "max avg. veggies" setting, gives the actual maximum feeding rate for the entire sim.  So, if I have 40 NRG per veggie and 1 max veggy, then there will be an absolute maximum of 40 nrg per cycle (this implies 1 chlr per veggy, as that is the most efficient).

These are just ideas I am throwing around, but the main goal is to make energy management and population control more intuitive and meaningful.

Solved Bugs / Are veggy population limits broken?
« on: February 23, 2014, 09:24:46 AM »
I think that veggy population limits have been changed since the introduction of chloroplasts.  I'm not sure of the specifics, but I'm pretty sure it works differently.  Anyways, it does not seem to be functional when I used the option to automatically give veggies some chloroplasts at birth.

I think that the following settings are the relevant ones:

  • Robots: Alga_minimalis (the original version without chloroplasts).  Set as repopulating.  5 individuals with 3000 energy.
  • Global settings: Start Repopulating Robots with 5000 Chloroplasts  (you may have to restart DB for this to take effect)
  • General settings:  40 NRG per veggy per cycle.  The four numbers in "rates for average repopulation" are set to 25, 10, 10, and 25.

Now, you should be able to run the simulation and see how the veggies are allowed to reproduce without bounds.  Even though the population limit is set to 25, there will soon be many hundreds of veggies.  Also, something else to point out is that the little "chlr" number at the bottom of the screen, which I assume is meant to measure the number of chloroplasts, never climbs above 11.  You can click on the individual robots to see that each has hundreds of chloroplasts.

Off Topic / The Four "Forgotten" Operators
« on: February 20, 2014, 07:33:25 PM »
I recently rediscovered four forgotten operators in Darwinbots.  They are clear, drop, swap, and over.  Why do I call these the forgotten operators? Because there was no reference to them anywhere on the wiki.  Anywhere.  Absolutely no mention or documentation.

The wiki had entries for clearbool, dropbool, etc. for the Boolean stack, but it did not list their integer stack equivalents.  These forgotten operators seem fully functional, and I have no clue why they were not listed anywhere.  They seem very useful.

Anyways, I created a category of operators on the wiki called "Stack Operators" which includes clear, clearbool, drop, dropbool, etc (6 pairs in total).

Here is the line of code, which makes use of 2.46's new advanced "root" command.

Code: [Select]
*.light 2 pow 3 root 2 pow 1386 mult 19601 div 32000 ceil
The main difficulty of writing this was to make sure that the number stays within the limits of what DB can handle, which is integers +/- 2000000000.  This involved finding the best rational approximation for the fraction \frac{\sqrt{2}}{20}.

So far, the most accurate version of the code is the following, which is probably twice as accurate:

Code: [Select]
*.light 39 3 pow mult 3 root 2 pow 39 div 2 pow 169 div 154 mult 19601 div 32000 ceil
The simplest version is the following, but it has horrible accuracy:

Code: [Select]
*.light 3 root 4 pow dup pyth 20 div 32000 ceil

Also, the following gives the maximum number of chloroplasts for a given light level.  Any more chloroplasts, and you will actually lose more energy than you make.

Code: [Select]
*.light 2 pow 3 root 2 pow 510 mult 3361 div 32000 ceil
All of these have some rounding issues, mainly due to the 3 root. I tested it and they are generally accurate to within a few percent. 

Bot Challenges / Write the best Nano-Bot (max DNA length of 32)
« on: February 16, 2014, 04:31:21 PM »
This is a straightforward challenge:  Write a bot which beats the other bots.


  • Use F1 rules/conditions to determine which species is superior.  Have your bot fight the previous bots.
  • DNA length is determined by the Darwinbots program, and it should measure 32 or fewer.  (Important note: the end command is always included in this count, even if you did not write it as part of your DNA.)

Why 32?  I had to decide on a number, and I figured that 32 was a power of 2 which was about the right size.

To kick things off, here is my starting entry.   It is basically a highly-compacted version of Animal_Minimalis.  It measures 30 base-pairs in length.

Code: [Select]
 *.eye5 0 >
 *.refeye *.myeye != and
 *.refveldx .dx store
 -6 .shoot store
 *.refvelup 30 add .up store
 314 rnd .aimdx store
 *.nrg 20000 >
 .repro inc

Suggestions / Poll: Refvar for viruses
« on: February 16, 2014, 01:15:16 PM »
I've been doing a lot of virus stuff lately, and I came up with this idea.  There should be a refvar to tell how many mkvirus commands are in an opponent's DNA.  It would work similar to how refvenom tells the number of strvenom commands in the DNA.

This would allow a robot to determine if another robot is infected with a virus.  For example, a robot might not normally attack conspecs, but could choose to attack infected conspecs to help prevent more infections. 

Also, for symmetry's sake, there could also be a myvar which does a similar thing.

From what I have read, the energy production of a single veggie is determined by the number of chloroplasts and the light level (which is itself dependent on the density of robots on screen, etc.).

I've done a lot of digging, and I haven't been able to find the formula which relates light level, # of chloroplasts, and energy production.  I managed to find this image, but I want to know the underlying formulas which created those lines on the graph.

I'm trying to write a "smart veggie" which determines how many chloroplasts it should produce for a given light level.  If anyone knows the math formula which calculates energy production, that would be greatly helpful.

Simulation Emporium / Small Viral Evolution Simulation
« on: February 12, 2014, 11:48:32 AM »
I decided to make a simulation in which I studied the evolution of viruses only. 

There are a few important things to note regarding the simulation
  • I ran this in version 2.45.03.  It works best without chloroplasts so we don't have to deal with making sure that the veggies are being fed.  I didn't want a focus on energy management, but rather the infectiousness of the virus.
  • For similar reasons, I set all costs to 0 except for the DNA length cost, which I changed so that veggies would die after having 1000 BP (speeds up the sim)
  • If the population fell too low, then it would be repopulated with the original virus.
  • I kept the population very small and in close quarters, to maximize infection rates and simulation speed.
  • It is currently at slightly over 3 million cycles.

I created a short "starter" virus, which contained a few functions I thought would be essential, as well as a few random numbers.

Code: [Select]
403 204 257 185 723 65 181 802 595 468 108 874 390 215 973 605 403 5
*.thisgene .mkvirus store
1 .vshoot store
*.thisgene 1 sub .delgene store
403 204 257 185 723 65 181 802 595 468 108 874 390 215 973 605 403 5
*.nrg 6000 > 50 .repro store

This includes functionality to reproduce (since the robot would have no other DNA), to replicate the virus, and to delete all previous viruses (since only the last virus in the genome would be able to replicate anyways).

Almost immediately, the viruses lost the functionality to delete previous viruses in the genome.  Why did this happen?  My idea is that the more viruses are in the genome, the lesser the chance that new viruses would be randomly inserted as the last gene.  Since viruses are only active as the last gene, this  increases the "active lifespan" of the current infection.

Next, major deletions occurred.  This shortened the virus and made replication faster.

Code: [Select]
403 204 257 185 723 65 181 802 595 542 dec
215 973 605 403 rnd start
*.thisgene .mkvirus store
1 .vshoot store
*.thisgene 1 sub 351 store
403 204 257 185 723 65 181 802 595 468 108 store

The above virus is the most current version.

I made several key observations:
  • There would be mass extinctions once the current generation of robot grew too large (genome-wise) and died out.  Then, the remaining robots had to infect the new robots with the current version of the virus.
  • The viruses didn't mutate very fast, at all.  Most mutations occurred in the inactive viruses buried in the genome, only mutation in the active infection would matter.  I couldn't decide on the mutation rate.  I think it was 1/32x most of the time, but I recently changed it to 32x.
  • Reproduction made no difference. Most of the time, the number of veggies maxed out.  Also, only one of the many infections needed to be able to reproduce in order for the robot to reproduce.
  • I probably should have made an empty host, rather than having the starter virus and the host robots being the same.  That way, we would not have to deal with the original virus being reintroduced, although that might increase competition.

Do you have any advice for future viral sims?  This first one was mostly an experiment to see if it were possible.  I think that the starter virus makes a huge difference as to what the final product will be, since DNA is deleted much easier than it is modified/added.  It is thus important to write an "easily evolvable" virus, which contains all potential functionality, and I don't know if I did a very good job this time.

RANT / Breaking news: Internet Mode horrible, non-functional
« on: February 10, 2014, 09:01:52 PM »
I have been using Darwinbots for several years, probably all the way back to 2010.  In all that time, I have never seen a single robot teleported into my sim from the internet.  Maybe I've gotten unlucky, only running sims when IM was down.  Maybe I've never managed to configure my settings properly.  I'm relatively certain, however, that IM is simply broken.

As far as I can tell, there is no evidence that Internet Mode even exists!  For all I know, it might all be a conspiracy or scam!

The internet teleporter always sucks up my good robots, but never gives me anything in return.  They are simply deleted, or otherwise cast into the empty void that is the internet.  It's like a black hole, more than once has my "king robot" fallen through the event horizon.

I really hope that we can find a fix for IM, hopefully sometime soon.

Bot Challenges / DNA Obfuscation Contest
« on: February 07, 2014, 08:42:24 PM »
This contest is similar in style to the "Obfuscated-C" programming contests.   The main idea is to take a simple robot, say Animal_Minimalis or something not-too-complex, and re-write its DNA such that it is unreadable yet similarly functioning.

  • Your goal is to cause onlookers to ask "How does that even work?!"  Try to take advantage of "hidden" functionality.  Impress people with your knowledge.
  • The DNA should be hard to understand, yet not too long.  It is relatively easy to write a humongous unreadable math expression, but your submission should not rely on sheer size to create unreadability.
  • The underlying robot behavior ("phenotype") should be relatively simple.  Write super-complex DNA for a simple bot.
  • Basic ideas include substituting numbers with their associated Sysvar names, or messing around with the data stack, or making certain things "conditionless."

For your submission, simply include the "before and after" of the obfuscation. 

There's not going to be an official judging/awards process, but I'm simply interested in seeing what people can write.  It's somewhat open-ended. Have fun!

Evolution and Internet Sharing Sims / Using Animal_Minimalis as a veggie?
« on: February 07, 2014, 07:57:57 PM »
I'm sure someone has had this idea before, but I haven't seen it mentioned. 

I've been trying to evolve a better robot, which I shall call Ultra, and I want it to become a better fighter.  I feel that using a passive veggie would probably not provide the correct selective pressure, since the feeding robots would not have to deal with being shot at.  In addition, I must have Animal_Minimalis set a veggie in order to make sure that it is not wiped out.

The main problem is that the Animal_Minimalis is able to eventually wipe out Ultra over time.   This doesn't mean that my robot is weak, as it easily wins in a 15v150 fight between the two species.  The problem is that, in this setup, one side effectively gets an infinite backup energy supply.

The food chain looks like this:
"Sun" → Animal_Minimalis ↔ Ultra
It is easy to see why the flow of energy into Animal_Minimalis is greater than the flow into Ultra, so it eventually wins over time regardless of how strong Ultra is.

I've tried a few handicaps to try and weaken Animal into a suitable veggy, such as fixing in place and giving a very low starting energy.  Fixing in place reduces the possibility of "ganging up" (so each Ultra bot only had a single enemy at time), but it gave rise to a weird "invisibility" bug in which a few of the fixed bots would act invisible to the other bots.  Giving it a low starting energy did not change much, because it also reduced the food supply for the Ultra bots.

I tried to fix the problem by adding a second veggie (like Alga_Minimalis), but that did not work out too well either.   There began to be the problem of certain Animal bots gaining enough energy so that they could stay alive perpetually.  They could kill any single Ultra bot which tried to feed off of them, and prevented the spawning of Alga since there were enough veggies to meet the minimum.

Is there any settings which I might change in order to make this work?  I need to find a balance in which the Animal population can be continuously re-spawned, but without causing the extinction of the Ultra species or the Alga veggie.

Is there a way to set a maximum energy for Animal? Would I have to code that into the bot?

Darwinbots3 / What have I missed? (and a lot of other questions)
« on: May 04, 2013, 07:41:58 PM »
First of all, my current version of DB dates to May 2nd, 2011.  Have there been any updates since then?

What progress has been made on DB3?

Is there even any ongoing development?

What list of features do the developers plan on implementing in DB3?

How many new features have been implemented so far?

When is the expected release date of DB3?

Has anything interesting gone on in the forums in the past several months that I was away?

Suggestions / Bot color as output and debugging tool
« on: July 21, 2011, 09:57:36 AM »
Today I was thinking about AI when I wondered how a bot could communicate with the outside world.  It would be easier to observe and debug the bot if you had some sort of indicater as to what the bot is thinking about.  I propose that we add a way for bots to change their color on command.  There are several uses for this:

  • You can have different parts of a multibot change to different colors.  This adds a visual effect, and can be useful to make sure all of the robots are doing the right thing and becoming the right part of the multibot.
  • Have the bot change colors when doing different things.  This also adds a visual effect and is also useful when making sure the robot is in the right "mode" of operation
  • As a debugging tool. You can program the bot so that it turns red if a certain gene activates, for example

Here are two ways to implement this:
  • Create a memory location for the color. The value is the color, with 0 = red and 32000 = purple.  This value does NOT reset after each cycle. There should be a way to turn this feature on and off.
  • Create three memory locations.  They are the red, green, and blue values for the color.  These memory locations do NOT reset after each cycle. There should be a way to turn this feature on and off.
This second option has an advantage over the first option. It is possible to debug/observe three things at once.  You have the bot that turns red if gene 1 activates, green if gene 2, and blue if gene 3.  If it turns black, you would then know that all three genes activated.  The first option, however, will only return blue, and you do not know whether genes 1 or 2 activated or not.

Bot Challenges / Shortest Fully Functional Bot
« on: April 28, 2011, 06:12:02 PM »
How short can a bot be and still be fully functional?  This is a competition to find out.  To be considered "fully functional" the bot must meet these qualifications:
  • Search for prey.  This can be as simple as turning or moving foward.
  • Pursue prey.  This means that the bot actively tries to get the enemy within range of attack.
  • Feed off of prey.  This can be as inefficiant as needed, as long as the bot gains net energy from the attack.
  • Not attack conspecs.  It should not treat conspecs as enemies.
  • Reproduce.  This should be controlled with some sort of condition.
  • Populate the sim in F1 conditions.  It will be released into an environment of Alga_Minimalis (modified to increase *.myeye if needed).
There are various awards for this competition. These are as follows:

PLATINUM- Shortest entry out of all of the entries that meets the above qualifications.
GOLD- DNA length under 25.
SILVER- DNA length under 35.
BRONZE- DNA length under 45.
COPPER- DNA length under 60.
QUALIFIER- Bot meets above qualifications.

It may seem like I set the bar high for the awards, but some are easier than you may think.

DNA - General / Help with .timer
« on: April 22, 2011, 11:31:47 AM »
I have been working on a simple, 7 neuron ANN bot.  Instead of changing the behavior of each neuron, the bot changes the connections between neurons.  Instead of learning off of it's past history, the bot copies the connections of conspecs with more nrg.  Each cycle, it chooses a connection using its timer.  It then puts the number into out1.  When another bot (with lower nrg) sees the bot with higher nrg, it takes its in1, and using the timer (modified to compensate for its increase over one cycle), it stores the number in the correct memory location, changing the connection.  The problem is that different bots seem to develop different timers, and this destroys the whole process.  How can I fix .timer to be the same for all of the bots?

I am willing to explain more about my bot if needed.

Here is the code:
Code: [Select]
*.robage 5 =
1 50 store 'establish a constant 1
50 rnd 100 store 'shoot threshhold
9 rnd 51 add 61 store 'neuron inputs (adding, constant 1 not allowed)
9 rnd 51 add 62 store
9 rnd 51 add 63 store
9 rnd 51 add 64 store
9 rnd 51 add 65 store
9 rnd 51 add 66 store
9 rnd 51 add 67 store
9 rnd 51 add 71 store
9 rnd 51 add 72 store
9 rnd 51 add 73 store
9 rnd 51 add 74 store
9 rnd 51 add 75 store
9 rnd 51 add 76 store
9 rnd 51 add 77 store
10 rnd 50 add 81 store 'neuron inputs (subtracting, constant 1 allowed)
10 rnd 50 add 82 store
10 rnd 50 add 83 store
10 rnd 50 add 84 store
10 rnd 50 add 85 store
10 rnd 50 add 86 store
10 rnd 50 add 87 store
10 rnd 50 add 91 store
10 rnd 50 add 92 store
10 rnd 50 add 93 store
10 rnd 50 add 94 store
10 rnd 50 add 95 store
10 rnd 50 add 96 store
10 rnd 50 add 97 store

 *.timer 36 mod .timer store 'mod timer by 36
 *.refvelup 58 store 'update inputs
 *.refveldx 59 store
 *.eye5 60 store
 *61 * *71 * add *81 * sub *91 * sub 50 ceil -50 floor 51 store 'neuron 1
 *62 * *72 * add *82 * sub *92 * sub 50 ceil -50 floor 52 store '2
 *63 * *73 * add *83 * sub *93 * sub 50 ceil -50 floor 53 store '3
 *64 * *74 * add *84 * sub *94 * sub 50 ceil -50 floor 54 store '4
 *65 * *75 * add *85 * sub *95 * sub 50 ceil -50 floor 55 store '5
 *66 * *76 * add *86 * sub *96 * sub 50 ceil -50 floor 56 store '6
 *67 * *77 * add *87 * sub *97 * sub 50 ceil -50 floor 57 store '7
 *51 1256 mod .aimdx store 'update outputs
 *52 50 mod .up store
 *54 50 mod .dx store
 *.timer 61 add * .out1 store 'select memloc using timer and put in out1

 *.refnrg *.nrg >
 *.refeye *.myeye =
 *.in1 *.timer 1 sub 36 mod 61 add store 'update memloc from in1 using timer

 *53 *100 > 'only shoot if above threshhold
 -1 .shoot store

Pages: [1] 2