Messages

1

Suggestions / Re: Population Control and Energy Management Aren't Intuitive

« on: February 24, 2014, 10:25:57 PM »

The main thing (which might have been just me)  is that the number 40 just felt like an arbitrary multiplier.  For example, it is hard to determine how much energy you are actually feeding the veggies, without doing a measurement after the fact.

Before chloroplasts were implemented, if I set "max veggies = 200" and "20 nrg per veggy," then I knew that there is going to be 4000 nrg created every cycle, as well as 200 veggy bots in the sim.  Now, if I set "max veggies = 200" and "20 nrg per veggy" then I honestly have no clue how many bots are going to be in the sim, or how much nrg is going to be created.

I feel that, in general, the settings tend to drastically underestimate the amount of energy put into the sim.  Why?  I think it has to do with the choice of light level as the "baseline."  Currently, 16000 light is the baseline (half the screen).  Does this ever happen?  If I put 1000 bots in a size 1 sim, then the light level is still slightly over 25000.  So, every veggie receives much more energy than what the settings imply. 

For example, take that one simulation in which there were 1000 veggies (16000 chlr each) in a size 1 sim.  There was 10000 total "avg" chloroplasts, a setting of 100 nrg per veggy, and a light level of about 25000.  The "intuitive prediction" is that the veggies will receive 1000 chlr * 100 nrg = 100000 nrg per cycle.  Rather, they receive 237000 nrg per cycle because of the very high light level. If you look at my attachment, however, you can see that it is very overcrowded and this doesn't make sense!

Nothing has to be fundamentally altered, you don't have to change any exponents (actually, please don't).  I think that there should be a "scaling factor" of sorts.   Basically, since the actual feeding rates are always higher than what the settings imply (since light level is always pretty high), we can divide the feeding rate by a scaling factor to make the effects more similar to what the settings imply.

I propose a scaling factor of 1/3.53929, which makes the "baseline" light level equal to 32000 rather than 16000.

To see how this makes things better, take the "intuitive" prediction of 100000 nrg for the sim I was talking about earlier.  Without the scaling factor, the sim receives 237000 nrg per cycle.  With the scaling factor, the sim receives 66963 nrg per cycle.  This is much closer to the prediction, given the insanely high amount of crowding which reduces light level.

2

RANT / Re: Of Many Celebrations! IM is working!

« on: February 24, 2014, 09:09:22 PM »

Thanks!

_{*My viruses have been released!*}

3

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.

4

Solved Bugs / Re: Are veggy population limits broken?

« on: February 23, 2014, 02:28:21 PM »

Okay, I'm pretty sure that I understand what is going on, but I do agree that we need to update the names of the settings.  To be honest, the current way of naming these settings is completely outdated with the addition of chloroplasts.

For example, "40 NRG veggy per cycle" no longer means "giving 40 nrg to each veggie every cycle."  I think we should rename it to something more descriptive.

Also, what is the logic behind dividing by 16000 to get "avg chloroplasts"?

5

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.

6

RANT / Re: Here is Practical Explanation about Next Life, Purpose of Human Life -

« on: February 23, 2014, 08:36:49 AM »

This person is bad news, because I have experience trying to moderate him.  He tends to create a new account every time we delete his current one.  I suggest an IP ban which applies to his city in India.

7

Off Topic / Re: The Four "Forgotten" Operators

« on: February 22, 2014, 07:23:10 PM »

Also, I found that the operators dupint dropint swapint clearint overint are functional, and are just different names for the same operators.

8

The Gene depository / Re: Powerful half-evolved shooting gene

« on: February 22, 2014, 06:54:06 PM »

Okay, so I cut out all of the junk DNA.  This way, we can see what the DNA is actually doing:

Code: [Select]

start
*.eyef 0 !=
 *.refxpos *.refypos angle .setaim store
 *.refxpos *.refypos dist 700 div *.maxvel mult *.refvelup add 9 floor *.maxvel mult .up store
 *.veldx .sx store
 -6 .shoot store
stop
So, by comparing the two versions, we can see that the .aimshoot line was rendered nonfunctional, as well as the .shootval line.  Those are the major changes.  A third change was *.maxvel ceil changing to *.maxvel mult in one location. 

I can't tell if the *.eyef line was in the original or not, but I assume it was.

9

Off Topic / Re: The Four "Forgotten" Operators

« on: February 21, 2014, 07:01:44 AM »

I haven't really found any reference to them on the forum either.  "Swap," for example, I only found in a robot's DNA.  "Over" just returned results about "overflow."

10

F1 bots / Re: BlueOnBlue evolved(evo)(F1)(MysticalDumpling)20-2-14

« on: February 20, 2014, 09:56:46 PM »

Interesting.  What do you think was the "major change" which made it work better than all of the other versions?

11

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

12

The Gene depository / Calculate ideal number of chloroplasts for a given light level

« on: February 19, 2014, 07:54:50 PM »

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 .

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. 

13

Bot Challenges / Re: DNA Obfuscation Contest

« on: February 19, 2014, 05:55:04 PM »

Try and figure out how my bot works.  It's probably not that hard, since it's pretty short.  I did use some different techniques than you.

Here is my attempt at understanding your bot's DNA:

Code: [Select]

cond
start
 .out1 inc
stop

cond
 *.nrg 500 >
start
 5 .repro store
stop

cond
 *.robage 1 =
start
 .deltie inc
 614 .setaim store
stop

cond
 *.eye5 0 >  'eyef and eye5 are the same since focuseye has not changed
start
 *.refxpos *.refypos angle .setaim store
stop

cond
 *.eye5 0 =
start
 50 .sx store
stop

cond
 *.in1 0 >
 *.eye5 0 > and
start
 *.refxpos *.refypos dist -- abs .up store
stop

cond
 *.eye5 9 >  'an error in your code made the *.refeye *.myeye part go unused
start
 .shoot dec
stop
end

I did find one error in your code, which is that 'and' should be 'mult' in the second-to-last line.  Overall, you did a pretty good job.

14

RANT / Re: Breaking news: Internet Mode horrible, non-functional

« on: February 19, 2014, 05:18:05 PM »

This is somewhat unrelated, but I think that IM should have some sort of Robot Cache.  When I am the only person running the program, then it seems like my robots get simply teleported out and then immediately back in.  Instead, it should keep a couple of the bots in a holding area.  That way, when I leave and someone like MysticalDumpling comes online, there are a few of my bots which can be sent to his sim even if I am not online.  Likewise, I could come online later and receive some of his bots.

15

Bot Challenges / Re: DNA Obfuscation Contest

« on: February 19, 2014, 07:15:54 AM »

Here is my current entry, although it is pretty short.  Just let it loose in an area with some veggies.  (tested in 2.46.02beta)

Code: [Select]

start
  ++ *.refeye = *.eye5 = .setaim 300 *.refvelsx .tieval 6 or
 store
 not &
 store
 *.refvelup
 *.eyef dup sgn 50 mult *.eyef >
 add dup sgn store -
 not 7 and store
 1000 mult *.nrg <
 store
end