Looking into memory snapshots

[PurpleYouko]

I have just started looking into the best way to implement memory snapshots.

There are three main approaches that I can see.

1) save the memory of the robots into the snapshot save file for offline use. This can either be added as part of the main snapshot file or added as a second complimentary file with just memories.

2) Online memory monitoring as an extension of the robot information panel. While it is already possible to see each of the robot's memory locations from the console, it takes a long time to check through them. A display could be set up to monitor all or a select few memory locations at each cycle of the sim.

3) A third approach could be to save the memory locations of one specific robot (as selected in the robot information panel) as a special kind of snapshot file. This will track ALL of the memory locations for the selected robot for as long as you like.

Personally I think 2 and/or 3 would work the best. I don't think 1 would be all that useful.

Thoughts please people?

[Endy]

I think #2 mainly since I normally monitor the numbers cycle by cycle when testing complex code for stuff like MB repro or when a series of actions are required. A way to monitor the top numbers in the stack would also be helpful(it's possible to rig something up but I'd rather not have to).

Endy :)

[Greven]

2 and 3 sounds good to me.

But what about the option to save only specific memory locations for all robots? Or was it abandoned?

Example:

You only what to look into memory location 201-207 and 509-512 (just picked out of the blue) over an entire run (x cycles)?

[PurpleYouko]

You only what to look into memory location 201-207 and 509-512 (just picked out of the blue) over an entire run (x cycles)?

 :blink:

That would be one [span style=\'font-size:14pt;line-height:100%\']HUGE[/span] file.

Even 10 memory locations saved for ALL bots (average of about 500) over 1,000,000 cycles would be a 5 GIGABYTE file.

That is why this option gives me headaches even thinking about it.

What I am thinking about is to have a recording function built into the console. It would allow for maybe 20-50 user definable memory locations to be constantly monitored, updated and displayed for each cycle for the selected robot.
A control could be set up to initialize a save file for this specific robot, then it could be saved to a file as well as monitored in the console for as long as you like. I would automatically include informational inputs like the eyes, shots hitting it and such like so that you can examine the file online and again offline afterward.

[Greven]

Okay 5 GByte is a little to much, my brain is running low on nrg at the moment.  ;)

But still you should have the option. Make so you can choose at which rate it would save. At 1000 cycles/save is only 5 MegaByte!

[PurpleYouko]

Maybe so but it would still take you a couple of years or so to make any sense out of the save file

[Greven]

No it would not! If the saved file has proper formatting, a program could make some beautifull statictics! But then again this could be done directly from DB...

[PurpleYouko]

I guess graphing it would be pretty easy but I'm not sure what that would really acheive.

The point of saving memory locations and/or stacks is that you can follow a specific organism through the cycles of its life and see exactly what external stimuli effect it and in what way.
Critically examining all the inputs and outputs for one robot over 1000 cycles is still a pretty tall order. I have spent hours just looking at a single robot in a given situation while attempting to analyze exactly what, where, when, why everything is happening.
A bunch of pretty graphs wouldn't tell me diddly squat about what I really want to know. Stuff like exactly how much is stored into .aimsx when I have a variety of different eye inputs.
Try running HDV4 for a few cycles to see what I mean.
He doesn't use simple turning with stuff like "If eye3 > eye5 then store 23 in aimsx"
He uses a complex and infinitely variable formula based on several eye inputs.

1000 cycles of memory information from a single HDV4 would take me a couple of days to really sort out.

[Numsgil]

The problem is just figuring out what it is you want to record in the bots memory.  Probably, the only useful things to record are memory locations that are set more or less at birth, or locations that directly relate to a bots success, like *.kills or *.body.

So you don't need to record 1000 memory locations.  You're probably only really interested in maybe 10.  Let the user create a small list of memory locations he wants to record.  Then record only when those memory locations change, and list how they changed.

Something like this:

robot 6985
born on 102540
died on 107654
*50
cycle# | value | changed by
102541 | 214 | self
103251 | 52 | positive shot
105315 | 314 | positive shot
107600 | 322 | self

In the end you really just want one snapshot tool.  Have it be able to record DNA, specified memory locations, and/or anything else you can come up with.

[PurpleYouko]

Agreed Num.
You certainly need a lot more than 10 memlocs saved though.
Maybe 10 user definable memlocs in addition to most of the senses.
We certainly need all the eyes, the refvars, the myrefvars (in case you want to see anyone messing with them) and a few others recorded all the time.
Possibly about 100 memlocs per cycle. That wouldn't bee too bad for a single robot but it would make a pretty big snapshot file.

[Numsgil]

Again, it depends exactly what it is you want to find.

AZPaul wanted to figure out how is sex selection memory locations were mutating.  So likely he'd only be interested in them.

As you want more and more data, you'll want fewer and fewer bots to be recorded (no use gathering 10MB of data.  It'll blow your mind).  Maybe a 'only record X% of bots' check could be included, or a simple 'snapshot' of all bots currently on the screen at this instant.

Point is if you create enough tool pieces the user can mix and match to creat the perfect recording tool for his present needs.