week11 tweaks
[lambda.git] / week11.mdwn
index be59f0e..a7558ff 100644 (file)
@@ -66,7 +66,7 @@ The kind of data structure we're looking for here is called a **list zipper**. T
 
 would be represented as `([30; 20; 10], [40; 50; 60; 70; 80; 90])`. To move forward in the base list, we pop the head element `40` off of the head element of the second list in the zipper, and push it onto the first list, getting `([40; 30; 20; 10], [50; 60; 70; 80; 90])`. To move backwards again, we pop off of the first list, and push it onto the second. To reconstruct the base list, we just "move backwards" until the first list is empty. (This is supposed to evoke the image of zipping up a zipper; hence the data structure's name.)
 
-We had some discussio in seminar of the right way to understand the "zipper" metaphor. In the case of the list zipper, I think it's best to think of the tab of the zipper being here:
+We had some discussio in seminar of the right way to understand the "zipper" metaphor. I think it's best to think of the tab of the zipper being here:
 
                 t
                  a
@@ -93,7 +93,7 @@ to represent a list zipper where the break is at position 3, and the element occ
 
 Now how could we translate a zipper-like structure over to trees? What we're aiming for is a way to keep track of where we are in a tree, in the same way that the "broken" lists let us keep track of where we are in the base list. In a particular application, you may only need to implement this for binary trees---trees where internal nodes always have exactly two subtrees. But to get the guiding idea, it's helpful first to think about trees that permit nodes to have many subtrees. Suppose we have the following tree:
 
-                                1000
+                                9200
                            /      |  \
                         /         |    \
                      /            |      \
@@ -118,9 +118,9 @@ Similarly for `node 50` and `node 80`. We haven't said yet what goes in the `par
 
        {parent = ...; siblings = [*; node 920; node 950]}, * filled by node 500
 
-And the parent of that targetted subtree should intuitively be a tree targetted on `node 1000`:
+And the parent of that targetted subtree should intuitively be a tree targetted on `node 9200`:
 
-       {parent = None; siblings = [*]}, * filled by node 1000
+       {parent = None; siblings = [*]}, * filled by node 9200
 
 This tree has no parents because it's the root of the base tree. Fully spelled out, then, our tree targetted on `node 50` would be:
 
@@ -129,20 +129,20 @@ This tree has no parents because it's the root of the base tree. Fully spelled o
              parent = {
                 parent = None;
                 siblings = [*]
-             }, * filled by node 1000;
+             }, * filled by node 9200;
              siblings = [*; node 920; node 950]
           }, * filled by node 500;
           siblings = [node 20; *; node 80]
        }, * filled by node 50
 
-In fact, there's some redundancy in this structure, at the points where we have `* filled by node 1000` and `* filled by node 500`. Most of `node 1000`---with the exception of any label attached to node `1000` itself---is determined by the rest of this structure; and so too with `node 500`. So we could really work with:
+In fact, there's some redundancy in this structure, at the points where we have `* filled by node 9200` and `* filled by node 500`. Most of `node 9200`---with the exception of any label attached to node `9200` itself---is determined by the rest of this structure; and so too with `node 500`. So we could really work with:
 
        {
           parent = {
              parent = {
                 parent = None;
                 siblings = [*]
-             }, label for * position (at node 1000);
+             }, label for * position (at node 9200);
              siblings = [*; node 920; node 950]
           }, label for * position (at node 500);
           siblings = [node 20; *; node 80]
@@ -226,7 +226,7 @@ where `node 500` refers to a tree built from a root node whose children are give
        {
           parent = None;
           siblings = [*]
-       }, * filled by node 1000
+       }, * filled by node 9200
 
 where the targetted element is the root of our base tree. Like the "moving backward" operation for the list zipper, this "moving upward" operation is supposed to be reminiscent of closing a zipper, and that's why these data structures are called zippers.