Browse Source

Updated README.md

master
ChristopherMahoney2000 3 years ago
parent
commit
be9a024307
  1. 9
      README.md
  2. BIN
      table.jpg
  3. BIN
      table.png

9
README.md

@ -3,7 +3,8 @@ In order to run my code you can simply call `./make.sh <file>`. The files `bit.t
My implementation for both jabber and wocky used the same fact about our compression table. Every prefix we add to our table was one bit appended to some previously seen prefix. This allows for some cool data structures.
**Jabber**
**Jabber:**
TJ had the idea to use a labeled binary tree that we can descend while reading in the prefix. Reading in a zero means descending left and reading a one descends right. Once we reach a leaf node we print it's label in binary and we add a new child node in the direction of the next bit, labeled with tree size + 1.
![](tree.png)
@ -12,12 +13,14 @@ Using a binary tree in this way means the time complexity for reading in a prefi
Ryan and I worked together on implementing Jabber but we wrote our own code.
**Wocky**
**Wocky:**
I wrote wocky alone and once again used the "each prefix = some previous prefix + 1 bit" property. Since at each step we read an index (integer) and find the prefix (string) at that index an array of cstrings would be sufficent. `char ** table = malloc(size * sizeof(char*))`. This can be done more memory efficently. Instead of storing cstrings I store a pointer to the previous prefix and 1 character representing the 1 new bit.
![](table.jpg)
Printing becomes a little more complicated since we can no longer just fprintf a cstring. All it requires is a little bit of recursive decent, unfortunately this can't be written tail recursively.
**atob and btoa**
**atob and btoa:**
I tried to optimize as much as possible without digging into assembly and calculating running times. They use lots of bit wise opperators.

BIN
table.jpg

Before

Width: 687  |  Height: 500  |  Size: 47 KiB

BIN
table.png

After

Width: 952  |  Height: 407  |  Size: 62 KiB

Loading…
Cancel
Save