Commit acb06725 authored by Filip Stedronsky's avatar Filip Stedronsky
Browse files

Succinct: SOLE: fixes, forgotten file

parent dbb630e7
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);
}
......@@ -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.
......
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment