Search and Representation

From Maze

Jump to: navigation, search

These notes will be developed into a chapter that opens discussion on the topics of search and representation.

For simplicity, let's refer to the two characters output by the program as "slash" (/) and "backslash" (\).

First section: an explanation of binary number. The output of the program is essentially a large, binary number. Each digit of the number is generated randomly. The number is broken into parts of equal length.

Second section: Write something like Casey's Processing translation in JavaScript. Make the background grid visible. Explore versions of the output using symbols other than slash and backslash; e.g., 1s and 0s or black and white squares. Explore versions in which the grid is changed or the size and/or alignment of the characters in the grid are changed. This will introduce some of the formatting issues I discussed in my initial post where I translated the program into one-liners in Perl and JavaScript. This should also connect well with some of the versions Jeremy has written. Perhaps connect this to some of the idiosyncrasies of BASIC's PRINT routine that Michael uncovered with PEEK and POKE.

Third section: Introduce the notion of combinatorics: How likely is it that the program will produce a screen full of diamonds? Or, of stripes? Or some other specific pattern?

Fourth section: Introduce topology and shapes: what does it mean to traverse the output as a maze? From any given position, one can potentially move in 6 directions: north, south, northwest, southeast, northeast, and southwest. If we think of a position in the maze as within a given row and between two columns (of the background grid), then the geometrical shapes of these positions can be articulated with four figures: (1) equilateral triangle with point up (Tup); (2) equilateral triangle with point down (Tdown); (3) rhombus leaning to the left (Rleft); (4) rhombus leaning to the right (Rright).

Fifth section: Introduce (visual) rules and grammars: Movement in the "maze" can be represented with 9 of the possible 16 couplets of these figures: NORTH-SOUTH: Tup-above-Tdown, Rleft-above-Rright, Rright-above-Rleft; NORTHWEST-SOUTHEAST: Rleft-above-Rleft, Tup-above-Rleft; Rleft-above-Tdown; NORTHEAST-SOUTHWEST: Rright-above-Rright, Tup-above-Rright, Rright-above-Tdown. (This will all be done graphically in the text and should be easy to understand, unlike my cryptic notation in this note.)

Sixth section: Write a JavaScript interpreter that takes a set of visual rules and the output of our program and searches the output from a given position. Connect this to Michael's walker code.

Seventh section: Extend the interpreter so that it takes a function that evaluates the output as a potential maze (e.g., does it offer a path from and entrance on the perimeter to a goal position in the interior that twists and turns enough and that offers enough blind alleys off the correct path to make it challenging?). The output for this will look like the output of our program, but will designate a start and end point on the "maze."

Eighth section: Extend the interpreter so that it searches the output for all disconnected regions and then colors them with the fewest colors possible. Connect to Noah's code for coloring the maze by "flooding." Introduce the four-color problem from mathematics.

Personal tools