Updated via commit to -Solution by beejjorgensen

Author: instruction-repo-generator[bot]

.gitignore

@@ -0,0 +1,2 @@
+__pycache__
+.vscode

README.md

@@ -1 +1,81 @@
-# cs-module-project-hash-tables
+# Hash Tables
+
+## Day 1
+
+Task: Implement a basic hash table without collision resolution.
+
+1. Implement a `HashTable` class and `HashTableEntry` class.
+
+2. Implement a good hashing function.
+
+   Recommend either of:
+
+   * DJB2
+   * FNV-1 (64-bit)
+
+3. Implement the `hash_index()` that returns an index value for a key.
+
+4. Implement the `put()`, `get()`, and `delete()` methods.
+
+You can test this with:
+
+```
+python test_hashtable_no_collisions.py
+```
+
+The above test program is _unlikely_ to have collisions, but it's
+certainly possible for various hashing functions. With DJB2 (32 bit) and
+FNV-1 (64 bit) hashing functions, there are no collisions.
+
+## Day 2
+
+Task: Implement linked-list chaining for collision resolution.
+
+1. Modify `put()`, `get()`, and `delete()` methods to handle collisions.
+
+2. There is no step 2.
+
+You can test this with:
+
+```
+python test_hashtable.py
+```
+
+Task: Implement load factor measurements and automatic hashtable size
+doubling.
+
+1. Compute and maintain load factor.
+
+2. When load factor increases above `0.7`, automatically rehash the
+   table to double its previous size.
+
+   Add the `resize()` method.
+
+You can test this with both of:
+
+```
+python test_hashtable.py
+python test_hashtable_resize.py
+```
+
+Stretch: When load factor decreases below `0.2`, automatically rehash
+the table to half its previous size, down to a minimum of 8 slots.
+
+## Day 3 and Day 4
+
+Work on the hashtable applications directory (in any order you
+wish--generally arranged from easier to harder, below).
+
+For these, you can use either the built-in `dict` type, or the hashtable
+you built. (Some of these are easier with `dict` since it's more
+full-featured.)
+
+* [Lookup Table](applications/lookup_table/)
+* [Expensive Sequence](applications/expensive_seq/)
+* [Word Count](applications/word_count/)
+* [No Duplicates](applications/no_dups/)
+* [Markov Chains](applications/markov/)
+* [Histogram](applications/histo/)
+* [Cracking Caesar Ciphers](applications/crack_caesar/)
+* [Sum and Difference](applications/sumdiff/)
+

applications/crack_caesar/README.md

@@ -0,0 +1,101 @@
+# Cracking a Caesar Cipher
+
+You're going to use _frequency analysis_ to crack a Caesar cipher to
+recover the key and the plaintext.
+
+## Caesar Ciphers
+
+These are methods of encryption where you take the _plaintext_ (the
+unencrypted text) and encrypt it by substituting one letter for another
+to produce the _ciphertext_ (the encrypted text).
+
+For example, we might have the following mapping (which is the _key_ for
+unlocking this cipher, not to be confused with a hash table key):
+
+```
+A -> H   B -> Z   C -> Y   D -> W   E -> O
+F -> R   G -> J   H -> D   I -> P   J -> T
+K -> I   L -> G   M -> L   N -> C   O -> E
+P -> X   Q -> K   R -> U   S -> N   T -> F
+U -> A   V -> M   W -> B   X -> Q   Y -> V
+Z -> S
+```
+
+So if you have plaintext like `HELLO, WORLD!`, use the above table and
+`H` becomes `D`, `E` becomes `O`, and so on to produce ciphertext
+`DOGGE, BEUGW!`
+
+To decode, just do the reverse, `D` becomes `H`, etc.
+
+But what if you evesdrop on some ciphertext, but don't know the key (the
+mapping). How can you decode it?
+
+## Frequency Analysis
+
+Turns out, letters occur in the English language with a known frequency.
+The letter `A` is 8.46% of all letters, for example.
+
+(Disclaimer: these are not the actual frequencies in general english
+prose. They're contrived for this specific challenge so that you get a
+decent result, but they're quite close to the real percentages.)
+
+| Letter | Percentage |
+|:------:|-----------:|
+|   E    |    11.53   |
+|   T    |     9.75   |
+|   A    |     8.46   |
+|   O    |     8.08   |
+|   H    |     7.71   |
+|   N    |     6.73   |
+|   R    |     6.29   |
+|   I    |     5.84   |
+|   S    |     5.56   |
+|   D    |     4.74   |
+|   L    |     3.92   |
+|   W    |     3.08   |
+|   U    |     2.59   |
+|   G    |     2.48   |
+|   F    |     2.42   |
+|   B    |     2.19   |
+|   M    |     2.18   |
+|   Y    |     2.02   |
+|   C    |     1.58   |
+|   P    |     1.08   |
+|   K    |     0.84   |
+|   V    |     0.59   |
+|   Q    |     0.17   |
+|   J    |     0.07   |
+|   X    |     0.07   |
+|   Z    |     0.03   |
+
+In other words, ordered from most frequently used to least, the letters
+are:
+
+```
+'E', 'T', 'A', 'O', 'H', 'N', 'R', 'I', 'S', 'D', 'L', 'W', 'U',
+'G', 'F', 'B', 'M', 'Y', 'C', 'P', 'K', 'V', 'Q', 'J', 'X', 'Z'
+```
+
+`E` is the most frequent letter. `Z` is the least frequent. And `M` is
+somewhere in the middle.
+
+So if you have a large enough block of ciphertext, you can analyze the
+frequency of letters in there. And if `X` is the most frequent, then
+it's a safe bet that the key includes this mapping:
+
+```
+E -> X
+```
+
+## Challenge
+
+Write a program that automatically finds the key for the ciphertext in
+the file [`ciphertext.txt`](ciphertext.txt), then decodes it and shows
+the plaintext.
+
+(All non-letters should pass through the decoding as-is, i.e. spaces and
+punctuation should be preserved. The input will not contain any
+lowercase letters.)
+
+No tests are provided for this one, but the result should be readable,
+with at most a handful of incorrect letters.