Fair Warning: what follows is a reflection that may be of interest to few (or none!) apart from myself.

My previous post on the Sierpinski Attractor jogged a long-dormant memory for me; a memory that prefigures an interest in programming and computer graphics.

My high-school calculus class required the purchase of a TI–82 graphing calculator; I was intrigued and fascinated by this gadget, and enjoyed tinkering with it and exploring its possibilities. I distinctly recall perusing the manual and encountering this:

I simply had to figure out how to make my calculator produce this image. Now, at the time, I knew absolutely nothing about programming a computer, calculator, or anything of the kind (the closest thing in my range of experience was probably a brief encounter with turtle graphics in elementary school), so when I tediously copied the Sierpinski program from the manual into my calculator, I had no understanding of how it worked. This was the program:

:If N≤1/3 
:.5Y→Y :End
:If 1/3<N and N≤2/3
:If 2/3<N 
:StorePic Pic6

Today, however, it’s not too hard to see that this program implements precisely the same algorithm we discussed in the previous post.

I was always bothered in those days how a random pixel, clearly not part of the figure, would intrude on the image — the sample above being a case in point. Now that rogue pixel’s appearance is explained as well — the algorithm is not deterministic, and while the probability of points produced by this method being outside the set may be vanishingly small, on a finite grid of pixels they stand out 1.

It’s also amusing to recall (via emulation) the execution speed:

And that was five times the actual speed.

It’s a strange feeling to look back and, in a way, have come full circle.

  1. In this way it’s the same as Cantor Dust; a set with Lebesgue measure zero rendered with infinite resolution would not be visible, however our finite-resolution renderings are only approximations, and therefore visible.