His first listed paper goes into 1D cellular automata, which is a subject I've always somewhat ignored, because 1D automata just didn't look as cool as 2D stuff. But his paper makes me want to explore it further.

He makes a pronouncement pretty early on -- there are 256 possible rules for 1D automata (those that only deal with yourself and your two neighbors), and of those rules, only 32 of them are "legal" rules, inasmuch as they won't disturb a completely empty world. I understand that distinction, because if they did disturb a completely empty world, then it would be possible that the rules themselves will create data that was never there before, rather than just data that results from the initial state and the application of the rules. Any rules that create data out of thin air would drown out any useful data that you started with. (I think that made sense -- I have an internal sense of what it means, but I'm not sure I can express it with any capability)

What I am frustrated with is that he doesn't go into any depth with a proof as to why it's only 32 rules, and when he specifies a general form for legal rules (at the bottom of this page), he does not explain why that's the form. Of course, it's probably obvious to him, or perhaps it's easy to prove. So now I'm spending some mental time trying to do the proofs myself.

Perhaps "proof" is too strong a word. I'm trying to convince myself that he is correct (which he certainly is, I'm just trying to mentally catch up to a paper he wrote in 1982, when I was a junior in High School).

This reminds me of when science scholars would work their way through Euclid, Doing all the proofs for themselves.

Hey, maybe I'll try that as well.

2:38:03 PM    comments ()  trackback []  

Surprisingly, the real struggle was coming up with a way to keep the generation algorithm in sync with the display. It was really easy to let it free wheel -- churning out generations as fast as possible while the display updates when it could. It was fun watching the gliders skip along, but sometimes you want to see every generation.

My first attempt at a solution was to have a loop that did a generation and then updated the display. The problem with that is that the program then stops responding to input, and you have to kill it.

What I really needed was a way to drive the generations using the event loop. The solution that worked was to use a one-shot NSTimer with a really short interval (I chose 0.001 seconds) that called the method that did the generation/display action. It worked well, running quickly, but showing each generation. Things ran slower, but still faster than any Python code I'd come up with, and faster than the Java code I was trying to beat.

The icing on the cake was using PyObjC to tie in to the pattern file readers I'd already written in Python. I wasn't looking forward to converting that code to Objective-C -- you can be really cavalier with memory usage in Python, and it would feel like a step backwards trying to figure out the right way to manage the memory in Objective-C. Besides, I'd already written it, and it worked. But I didn't have to. I followed the steps in the tutorial about adding Python code to an existing Objective-C program, and It Just Worked (tm).

9:46:30 AM    comments ()  trackback []  

I like that the new one is played straight. Yeah, it's a B-movie, but I like b-movies. It's fun, it's got the spaceships and the tough fighter jocks and the difficult life-or-death decisions to be made.

I liked the new version, and I'm looking forward to watching the conclusion tonight.

9:35:44 AM    comments ()  trackback []