Home Gallery
| Previous | Next |

Expansions: History: The Second Stage: BINDEZ Permutations and XPAND

Sometime in the academic year of 1970-1971 I drew about a half-dozen new patterns within a couple of days. I drew just a few Cycles of each pattern, enough to get their flavor. At this time I realized that there was a huge number of possible patterns. In the spring of 1971, I was writing a completely different kind of pattern generator on a college CDC 6400 computer and the thought occurred to me that I should be able to generate "my" patterns by computer.

At the end of the several years of relative inactivity there came to be the "Lindenwood" stage, primarily in the academic year of 1972-1973. This is when I first programmed Expansions to run on a computer. I enrolled in an independent study course to learn assembly language in order to program the IBM 1130 computer at The Lindenwood Colleges in St. Charles, Mo. The name of the Expansions program originally was BINDEZ (Binary Design), and I called the patterns it generated BINDEZ Permutations. I then continued the project under another independent study course under The Department of Art in order to finish writing the program and obtain academic credit at the same time. I listed the title of the course as "BINDEZ Permutations". I later renamed the computer program to "Expandsions" with an intentional misspelling (later corrected) and abbreviated the program's name to EXPND and then later to XPAND (perhaps inspired by IBM's abbreviation of "execute" as XEQ). I believe the length of the computer file names was restricted to five characters.

Lindenwood's IBM 1130 computer had 16K bytes of memory (8K of 16 bit words). I was able achieve a 620 by 620 grid unit growing array by assigning one bit per grid square and restricting the growth within a 1/8th wedge that was folded into a rectangle (Figure 2.1). This permitted the jamming of the pattern growing array into about 6K. Printing involved unfolding the 1/8th wedge into a full square. Ironically, I could not grow the Line Pattern because that pattern is not symmetrical in the eight primary directions I used. XPAND printouts were limited to characters on a drum printer that printed 10 mono-spaced characters to an inch horizontally and six or eight lines per inch vertically. Input was via a Selectric typewriter-like console. The program's source code was maintained on a deck of IBM Hollerith punched cards.

Figure 2.1. XPAND pattern growing array (gray): fitting into tight places.

While this scheme did not allow for adequate exploration of asymmetric patterns, I did spend enough time working on "wedge boundary transparency" to enable the growing of the other four original patterns, including the more complicated Great Pattern, without any problems.

Programming XPAND required defining exactly what it was I wanted to be able to do and what the limitations were to be. The limitations due to the machine environment were substantial. The final specifications were as follows: a Cycle could have a maximum of six Modules. A Module had to have two branches from its starting point and the branches had to be both long or both short. From each of the branch's first-parts there could be a second branch, also short or long. If one first-part had a second-part branch, then the other first-part branch had to have a second-part branch of the same length. The branches could be symmetric (Figure 2.2a) or asymmetric (Figure 2.2b). Both branches of asymmetric Modules had to bend at the same angle. If the first-part branches went straight ahead, XPAND still considered the Module as having two first-part branches, with each second-part, if present, assigned to one of the first-part branches. The idea of supporting asymmetric Modules grew out of bug that surfaced when trying to grow certain Modules.

Figure 2.2a. (left): XPAND Symmetric Modules
Figure 2.2b. (right): XPAND Asymmetric Modules

In XPAND, the collision rules were preset and not changeable. I established and programmed the rules in the fall of 1972.

The user interface to the XPAND program was quite crude by today's standards. Each Module was input via the computer's keyboard as a string of digits (there was no screen). The eight possible directions a Module could grow, for example, were codified by digits one through eight with "4" being straight ahead. Experimenting with patterns on the IBM 1130 was a hit and miss affair. The only indication I had that a pattern was growing was the blurring of the hexadecimal status lights. If the program "blew up" the lights just stopped. There were no display screens, debuggers or core (memory) dumps. So when I designed a pattern, I had to wait for the pattern to print out slowly line by line on the IBM 1132 printer, after it was grown, to find out "what it did."

Despite these limitations, many new patterns were grown, and I did not keep records of them all. Although the 16K computer was a single user computer and the only computer anywhere on the Lindenwood campus, it was usually available several evenings a week, and occasionally on weekends, when I could get the keys to the building from Security. Many times I was so frustrated that the building was locked, or if I could get in, the computer was being used!

The first Expansions pattern ever grown by computer was the V Pattern (see manual era)

The Triangles Pattern

One of the first new patterns grown by machine, in either very late 1972 or early 1973 (the year I officially use) was incredibly exciting. I wanted to grow one of the patterns I had designed earlier on graph paper. Due to mistakes in reverse engineering the pattern into a string of digits that I could enter into the program, I ended up with a different pattern I called "the random triangle generator" and later, just Triangles. Here I thought patterns created by Expansions were always predictable and periodic and then I stumbled across an incredibly beautiful random pattern! This was just an astonishing revelation to me! I spent a lot of time trying to understand its randomness (and failed). It just "is"! My first contact with "randomness" was in my fourth manually drawn pattern, the "Egg Pattern", but it wasn't until this pattern, with its startling randomness, that I developed second wave of "awe". The first wave was with the very first pattern. The Modules defining Triangles are shown in Figure 2.3a and portions of the first two Cycles are shown in Figure 2.3b.

Figure 2.3a and 2.3b: The Triangles Pattern

In XPAND I came up with a new variable I now call Bypass. This value of this variable bypasses the collision rules for a specified number of Modules in the first (and only the first) Cycle. This gives a pattern a better chance to get started. In the Triangles Pattern, as shown in Figure 2.3b, the pattern would have stopped growing at the end of the second Module round, if this option were not in effect. As alluded to earlier, for the Great Pattern to grow as shown in Figures 1.8b, 1.9a and 1.9d, Bypass would have to have been set to one. Figure 2.4 shows some of the "random" triangles generated by the Triangles Pattern.

Figure 2.4. The Triangles Pattern, Inverted. Scale: one pixel.

The thing that I really like about Triangles is the varied areas of similar and different sized triangles. The distribution of blips at the base of each triangle is a study in itself (which I later conducted in 1974).

Figure 2.4b. Another view of Triangles - Manually colored
This image was uploaded to a CompuServe library in 1991
Black and purple side areas manually added, not part of the pattern
Note: Pixel Pathways is no longer operating

The Venus Pattern

After the major bugs in XPAND were solved, I began designing patterns more complex than those I had drawn by hand. The "Venus" pattern was probably the first pattern I deliberately designed ahead of time to be grown by computer. I designed the pattern so that it would have to grow four Cycles before the outer-most running edge active points would be pointing in the same direction as the starting points for the 1st Cycle. I wanted curves to appear. Of all the new patterns I grew at Lindenwood, this was one of the most beautiful. I displayed a printout three pages wide of the Venus Pattern at the annual Lindenwood Student Exhibition in 1973. The Venus pattern is an asymmetric pattern, but was made eight-way symmetric due to the storage method shown in Figure 2.1. The figures included here show the way the Venus Pattern actually grows in unrestricted space.

Figure 2.5a. (left): Venus Pattern Modules
Figure 2.5b. (right): Venus Pattern Genesis

The six Modules are shown in Figure 2.5a. The starting point of each Module is highlighted by a hollow square to reduce ambiguity. Figure 2.5b shows the first two Module rounds of the Venus Pattern. This pattern at times appears to be wild and complex (Figure 2.6a and 2.6b), yet in accordance with the Power-Cycle (powers of 2), periods of uniformity emerge (Figure 2.7a).

Figure 2.6. Venus Pattern after six Cycles. Scale one and three pixel(s) with different starting directions.

Figure 2.7a. Venus Pattern, passing through 64 Cycles.

In Figure 2.7a the section of uniformity grew from left to right and was associated with the sixth Power-Cycle (64 Cycles). The distinct structure has 16 segments on its right hand side. Shortly after the seventh Power-Cycle (128 Cycles) a similar structure appears and it has 32 segments on its right hand side. The repeatability of this pattern is based on the same exponential pattern evident in the simpler patterns- just like the "straight edge" markings in the Line Pattern. Figure 2.7b shows other shapes that form when the Venus Pattern is grown at another scale.

Figure 2.7b. Venus Pattern. Scale: two pixels.

| Previous | Next |

© John S. Stokes III - Inventor, Artist, Puzzle Maker & Webmaster