Code center > Old Suggestions Awaiting Programming

Simulation tools Part 2

(1/3) > >>

AZPaul:
It's my own *^%# fault. I just assumed. Almost a religious zeal of surity.

I've gotten around the issue of .sexrepro and have a basic sim with just the right veggie count, energy count, bot count, field size, working DNA, does what I want in the way I want it done. I can run a million cycles maintaining a stable population under selection pressures with no halts, crashes, finger pokin' repopulates. No messiness. I'm ready.

Then reality hits. Bummer.

Hypothesis

Certain sexual selection criteria will inevitably lead to "runaway" overexpression of those attributes upon which the criteria are based. Bird tail length being the attribute in my sims.

Female selection of mates based upon the males tail length is set within a certain range. Not too big, not too short. Random shifts in available males together with random shifts in female preferences would seem to produce a random mix of population over the generations.

Except:

There is a restraining wall to the left side of the curve. You cannot have negative tail length. There is only one direction for the "random" shifts to populate over time and that is to the right side of the curve (larger length/preference). Over generations, therefore, the base average tail length will move right (get bigger). Then, with female preference for longer tails and more males with longer tails, the selection scope becomes a self-enforcing cycle and will, in theory, lead to explosive growth in even longer female preference and male tail length.

This is an experiment to test the hypothesis. As you well know, in experiment you strictly control all variables except the ones you wish to test. DBII mutation control is too varied. It turnes ".tail_length" into ".mkvirus" or memloc "981" into ".up" or "*.sex 1 =" into "*.repro 1 =" and so on. You end up with females mating with females and androgenes creatures mating with everyone, including veggies.  Not very realistic in this instance.

Through the free memory values I can "simulate" mutations of my test variables more closely and more realistically.

I had assumed snapshot would give the bots DNA and memory values. I could then import to Excel and manipulate the data. Wrong!

I can't get to the data!  I refuse to go through one bot at a time recording memory values from the console for 600 bots.

May I have access to Bot memory, please? Preferably from within a .txt file like Snapshot? Please?

-P

PurpleYouko:

--- Quote ---May I have access to Bot memory, please? Preferably from within a .txt file like Snapshot? Please?
--- End quote ---

Now that is one of the most well thought out requests for a long time.  B)

Shouldn't be too hard. I will see what I can do.

PurpleYouko:
OK I thought aboput it a bit and came up with a bit of a problem with using memory values in Excel.

Excel can only have a maximum of 256 columns so it becomes a little tricky to upload 1000 memlocs for each bot. For one thing, you couldn't use the regular method of opening the file or else you will get memlocs wrapping around onto different lines all over the place and making a right old mess.

This will take a bit more thought than I thought, I think  :wacko:

Numsgil:
It also seems that an idea I had way back in January might be of use here if well implemented.

I had considered adding NOTMUTABLE/MUTABLE sections to the DNA.  Mutations could be turned on or off in different sections of the DNA to allow you to strictly monitor and control where mutations may occur, for experiments like you describe.

shvarz:
Yes, I think Nums' idea would actually help AZ a lot more than the "memory snapshot".

Navigation

[0] Message Index

[#] Next page