Succinct: SOLE: fixes, forgotten file

fs-succinct/sole_common.asy

+import ads;
+
+real blockwidth = 1;
+real blockheight = 0.5;
+real arrowheight = 1;
+real rowheight =  blockheight + arrowheight;
+
+
+void mixarrow(int row, int col) {
+    real x = col * blockwidth;
+    real y = -row * rowheight - blockheight;
+    path arr1 = (x + blockwidth/2, y) {S} .. {S} (x + blockwidth, y - arrowheight / 2) {S} .. {S} (x + 1.5*blockwidth, y - arrowheight); 
+    path arr2 = reflect((x + blockwidth, 0), (x+blockwidth, 1)) * arr1;
+    draw(arr1, Arrow);
+    draw(arr2, Arrow);
+}
+
+void thruarrow(int row, int col) {
+    real x = col * blockwidth;
+    real y = -row * rowheight - blockheight;
+    draw((x+blockwidth/2, y)--(x+blockwidth/2, y-arrowheight), Arrow);
+
+}
+
+void block(int row, int col, string alphabet) {
+    real xbase = col * blockwidth;
+    real ybase = -row * rowheight;
+    if (alphabet == "...") {
+        label("$\cdots$", (xbase+blockwidth/2, ybase-blockheight/2), (0,0));
+        
+    } else {
+        if (alphabet != "EOF" && alphabet != "0")
+        draw((xbase,ybase)--(xbase+blockwidth, ybase)--(xbase+blockwidth, ybase-blockheight)--(xbase, ybase-blockheight)--cycle);
+        label("$"+alphabet+"$", (xbase+blockwidth/2, ybase-blockheight/2), (0,0));
+    }
+}
+
+void blocks(int row ... string alphabets[]) {
+    for (int i = 0; i < alphabets.length; ++i) {
+        block(row, i, alphabets[i]);
+    }
+}
+
+void thruarrows(int row, int col, int cnt) {
+    for (int i = 0; i < cnt; ++i)
+        thruarrow(row, col+i);
+}
+
+void mixarrows(int row, int col, int cnt) {
+    for (int i = 0; i < cnt; i += 2)
+        mixarrow(row, col+i);
+}
+
+void passlabel(int row, string lbl) {
+    label("{\it " + lbl + "}", (-1, -row*rowheight-blockheight - arrowheight/2), W);
+}
+
+

fs-succinct/succinct.tex

@@ -154,24 +154,27 @@ into a pair from alphabets $[C]$ and $[D]$ as long as $C\cdot D
 possible input combinations).
 
 We will use this kind of alphabet re-encoding by pair heavily in the SOLE
-encoding. The best way to explain the exact scheme is with a diagram:
+encoding. The best way to explain the exact scheme is with a diagram (fig. \figref{sole}).
 
 \figure[sole]{sole.pdf}{}{SOLE alphabet re-encoding scheme}
 
 There are two re-encoding phases. The first transforms blocks with alphabet
 $[B+1]$ into blocks with variable alphabet sizes (of the form of alternating
-$[B+3k]$, $[B-3k]$). The second phase runs phase shifted by one block and converts
-the variable-alphabet blocks into blocks with alphabet $[B]$.
+$[B+3k]$, $[B-3k]$). This is the origin of the name: after this pass,
+odd-numbered blocks have smaller alphabets than even-numbered ones. The second
+pass runs phase shifted by one block and converts the variable-alphabet blocks
+into blocks with alphabet $[B]$.
 
 What is the redundancy of this scheme? That depends on whether the original
 number of blocks (after padding) is even or odd. Figure \figref{sole} showed
 the case for an odd number. For an even number, the ending is a little bit different
 (fig. \figref{sole_even}).
 
-You can easily check that this is reversible: after decoding phase 2, the last block
-will always be either 0 (for the odd case) or EOF (for the even case).
+You can easily check that this is reversible: after performing the inverse of
+pass 2, the last block will always be either 0 (for the odd case) or EOF (for
+the even case).
 
-\figure[sole_even]{sole_even.pdf}{}{SOLE alphabet re-encoding scheme}
+\figure[sole_even]{sole_even.pdf}{}{SOLE alphabet re-encoding scheme, alternate ending with even number of blocks}
 
 Now we can finally analyze redundancy. Let us count how the number of blocks
 increases throughout the encoding passes.