Joby Elliott

• 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