Joby Elliott

• Not much to report code-wise. I've mostly just been running experiments and working on my paper.
• Tonight I'm probably going to actually make one tiny change to my code – I need to so I can get a higher resolution on one of my independent variables. Something interesting might be happening very close to zero.

• Script that runs through various parameters and calls a given number of mfms runs with each value now works
• Unsurprisingly, the super-basic experiment I had set up does not produce a U-shaped curve
• The scripts for gathering data are fairly flexible – I should be able to also use them for counting individual occurrences in the log files, too.
• That might be useful for quantifying something about how swarms work, because I'm still interested in building mobile swarms of beacons.
• Now that my data-gathering tooling is working I'll be getting back to aggressively expanding what my actual project code can do, and hopefully soon find a U-shaped curve somewhere. I had kind of put my actual ULAM code by the wayside to work on this stuff, because I wanted to have thorough data for Monday's presentation, even if it was of something really boring.
• I should be able to iterate and quantify at a fairly fast pace now, since I can use these scripts to get quantitative data out of some thousands of AEPS/minute.

• Parsing log files to make CSV data files of AEPS to completion from a series of experiments … [drumroll] … works
  • [this is me high-fiving a million angels]
• Now I need to finish the bits that will step through multiple parameter values, running a given number of experimental runs for each one

• Scripting simulator runs is totally working!
• I have a Node script that sets a parameter in an ExperimentParameters quark, compiles everything, and spawns/managees mfms processes
  • Has arguments for declaring what parameter to set, what to set it to, how many runs to do, and how many processes to run concurrently
  • mfms is set to end when the grid is full, so runs decide when to end by having some sort of monitor atoms that decide it's done and turn into a cancer
  • Decides on a name for this particular experiment instance and tells mfms to put all the logs and whatnot in a folder with that name in tmp
  • Apparently the multi-threading stuff that AMD got sued over for advertising my processor as 8 core when it's *really* 4 works well enough in this case. Running 4×4 tile simulations with two going simultaneously is almost twice as fast as running them consecutively. It takes like 53% as long.
  • Actually, it turns out running 6 at once is even faster. I'll have to see how many I can run at once before it starts to turn around. That's going to be a whole exercise in finding a u-shaped curve all its own.
• Next I need to make a script for this one to call, that searches the log files for the data I'm logging and saves it into a simple data file.
• Then I need a master script that iterates through my independent variable, calling this one a bunch of times. If I do like 100 runs per parameter value, and my parameter has 100 values, this could easily take 24 hours per experimental run – but will generate a lot of data in that time. 10,000 data points! It's a good thing hard drives are big in 2017, the whole mfms logging parts will probably fill my temp directory with about 20 gigabytes of logs per full experiment.
• I also want to make what mfs file to use as the starting environment an argument for this script. That way I can keep multiple experiment-starting mfs files around, not have to call them all “harness.mfs”, and be able to switch between them without needing to dig past versions out of git.

• Slightly belated log update concerning mostly what I did last week/end, and the tiny amount I got done yesterday
• Figured out the workflow for making recordings with mfms
• Made an extremely simple Seeker/Nest experiment, collected data from 25 runs of it for a graph. It was not a particularly interesting graph, in the end.
• Learned about how to run mfms with no GUI, started working on a plan to script the setting of parameters, compiling, and execution of experimental runs. Basic script process will be
  • Set parameter to what it needs to be in some source file
  • Compile
  • Run experiments with GUI-less mfms – since the time it takes will be variable, I'm planning on terminating experiments programmatically using a super cancer and the flag for mfms to automatically stop when the board is full.
  • Parse log files to figure out how long things took. This should be pretty easy, since most of my experiments are going to be simple AEPS counts of how long it takes a certain number of things to find their way to some other thing. Although logging whenever a “good” or “bad” thing happens would also be easy to parse later and turn into data.
  • Record all that data somewhere.
• Did some refactoring and organizing of my source code toward the ends above. Set up a new working directory that's focused on my first potential experiment, and pulled in only the code needed for that experiment. Also refactored to move all my potential independent variable parameters into one file, so it will be easy to script changing them.
• Today I'm probably just going to take a leisurely walk through the gnuplot documentation, so I have some idea how to format my data files so that I can turn them directly into graphs.

• Rewrote how directions are stored – Beacons now store an array of 4 Bools instead of a number 0-7. It uses one more bit, but is a lot easier to work with.
• Saved the bit I lost storing directions by dropping the number of bits to represent the burn state. To adjust the speed of burn recovery, it now only has a random chance incrementing its burn state when it behaves. This seems to work well enough. As long as the odds are fairly low, it all evens out and large swaths of beacons tend to all recover from burns at close enough to the same rate, even though burn states are now only 3 bits.
• Moved methods for picking a diffusion target sites into the quark that holds directions.
• Moving everything into the direction-keeping quark also gives me the option of changing how it stores directions, and maybe getting that bit I lost back at some point (if I ever need it). I just need to make sure that I actually use the proper interface of this quark everywhere its information is needed.
• Wrote a SlowGuy element that just burns cycles when it's his turn. His purpose is to artificially bog down a tile so I can play with how burning routes around slow areas.
• Finally, thanks to all that stuff, I have some demo Seeker elements that try to find a particular nest.
• The seekers mostly work, but … could be better.

• I spent a lot of the last few days off the grid, and didn't get much concrete lines-of-code-written sort of stuff done on my project.
• It did give me a lot of brain cycles to read well for the iron reader though.
• Still working on nest-seeking atoms (in the form of a generic beacon-reading quark)
• Trying to stop thinking about bonds and cell walls.
• Maybe I should have done bonds for my project.
• Having some ideas about how to use oscillators in beacons, but:
  • I probably (definitely) don't have the bits in my budget
  • It's probably a bad idea in general, because the beacons being unsynchronized gives them the unexpected bonus of creating paths around areas with exceptionally slow time, and synchronizing them would break that.
• Also thinking about how seekers should keep a rolling average sort of opinion about what direction signals are from, so they can handle those cases where a beacon signal wrapped around an obstruction and hit itself. If I don't introduce some inertia and/or randomness to how beacon following elements behave they could conceivably get stuck walking back and forth in that type of area.

• I've got a generic Beacon template and default quark built from it. It works for recording the direction a signal came from, and tracks three channels separately, so it can point the way to three things.
• Building all beacons from one base quark is working well, because it makes everything I'm building out of it interoperable.
• I've expanded that into an element that acts as a beacon and tries to spawn copies of itself so that it always has a beacon of some kind in every cardinal direction.
• I have a couple “nest” elements that also act as beacons, but broadcast to beacons around them on two of the three channels.
• My first test is going to be building atoms that spawn other atoms that try to find their way to a nest. Now that the guts of the beacons is working, I should be able to get that working tomorrow and have something relatively interesting to show and tell in class this week.
• For now I'm looking to get a baseline gut feeling of how well it works with stationary beacons, and then move onto using moving beacons.

• This weekend I did the reading on the paper, and played around a little with the sandpile element
• I also looked up how HSV to RGB conversion works, because I really want to be able to work with colors in HSV. I might actually look into adding HSV/RGB conversion functions to ColorUtils. It's a small thing, but I keep wishing I had it.
• I generally did not get as much done this weekend as I would have hoped – I kind of just spent my entire weekend on endless computer and network problems instead.

• worked on building a better sandpile element, with methods to use for toppling grains
• the idea is to use a consistent interface to build new things on top of the toppling, in particular I have this crazy idea of using topple events to propagate messages
• `ulam -i` is my favorite thing this weekend

• updated my wiki pages to make it all a little easier to follow, finally added a work log