Commit bd5efc3a authored by Danny Allen's avatar Danny Allen
Browse files

Updates formatting.

parent f510df12
Pipeline #140780 canceled with stage
# Project 1 (Zip) Write-Up #
--------
#### How Was Your Partnership? ####
- Did both partners do an equal amount of work? If not, why not?
If so, what did each person do? What happened?<pre>
## Project Feedback ##
### How Was Your Partnership? ###
- How was your partnership? What worked well? What would you do differently next time? <pre>
**TODO**: Answer this question
</pre><br>
-----
- Did both partners do an equal amount of work? If not, why not? If so, what did each person do? What happened? <pre>
**TODO**: Answer this question
</pre><br>
### Project Enjoyment ###
- What was your favorite part of the project? What was your least favorite part of the project <pre>
**TODO**: Answer this question
</pre><br>
#### Project Enjoyment ####
- What was your favorite part of the project? What was your least
favorite part of the project?<pre>
- Did you enjoy the project? Why or why not? <pre>
**TODO**: Answer this question
</pre><br>
- Did you enjoy the project? Why or why not?<pre>
- How could the project be improved? <pre>
**TODO**: Answer this question
</pre><br>
-----
#### WorkLists, Tries, and Zip ####
- The ADT for a WorkList explicitly forbids access to the middle elements. However, the FixedSizeFIFOWorkList has a peek(i) method
which allows you to do exactly that. Why is this an acceptable addition to the WorkList ADT in this particular case but not in general?
In other words, what about fixed size FIFO worklists makes peek(i) make sense? Why does peek(i) NOT make sense in other worklist implementations?<pre>
## WorkLists ##
### peek(i) ###
The ADT for a WorkList explicitly forbids access to the middle elements. However, the FixedSizeFIFOWorkList has a peek(i) method which allows you to do exactly that. Why is this an acceptable addition to the WorkList ADT in this particular case but not in general? In other words, what about fixed size FIFO worklists makes peek(i) make sense? Why does peek(i) NOT make sense in other worklist implementations? <pre>
**TODO**: Answer this question
</pre><br>
- As we've described it, a `TrieMap` seems like a general-purpose replacement for `HashMap` or `TreeMap`. Why might we still want to use one
of these other data structures instead?<pre>
## Tries ##
### TrieMap vs. (HashMap and TreeMap) ###
As we've described it, a `TrieMap` seems like a general-purpose replacement for `HashMap` or `TreeMap`. Why might we still want to use one of these other data structures instead? <pre>
**TODO**: Answer this question
</pre><br>
- One of the applications of Tries is in solving Word Searches. A "word search" is an n x m rectangle of letters. The goal is to find all
of the possible words (horizontal, vertical, diagonal, etc.). In Boggle, a similar game, any consecutive chain of letters
are allowed. Explain (in very high-level pseudo-code) how you might solve this problem with a TrieSet or a TrieMap. Make sure to detail
how a similar solution that uses a HashSet/HashMap instead would be different and why using a Trie might make the solution better.<pre>
### Applications of TrieMap ###
One of the applications of Tries is in solving Word Searches. A "word search" is an n x m rectangle of letters. The goal is to find all of the possible words (horizontal, vertical, diagonal, etc.). In Boggle, a similar game, any consecutive chain of letters are allowed. Explain (in very high-level pseudo-code) how you might solve this problem with a TrieSet or a TrieMap. Make sure to detail how a similar solution that uses a HashSet/HashMap instead would be different and why using a Trie might make the solution better.<pre>
**TODO**: Answer this question
</pre><br>
- One of the classes in the main package is called Zip. This class uses your PriorityQueue to do Huffman coding, your FIFOQueue as a buffer,
your stack to calculate the keyset of a trie (using recursive backtracking), and your SuffixTrie to do LZ77Compression. Find some text file
(a free book from https://www.gutenberg.org/ or even the HTML of some website) and use Zip.java to zip it into a zip file. Then, use a
standard zip utility on your machine (Finder on OS X, zip on Linux, WinZip or the like on Windows) to UNZIP your file. Check that you got back
the original. Congratulations! Your program correctly implements the same compression algorithm you have been using for years! Discuss in a
sentence or two how good the compression was and why you think it was good or bad.<pre>
## Zip ##
### Running Zip ###
One of the classes in the main package is called Zip. This class uses your PriorityQueue to do Huffman coding, your FIFOQueue as a buffer, your stack to calculate the keyset of a trie (using recursive backtracking), and your SuffixTrie to do LZ77Compression. Find some text file (a free book from https://www.gutenberg.org/ or even the HTML of some website) and use Zip.java to zip it into a zip file. Then, use a standard zip utility on your machine (Finder on OS X, zip on Linux, WinZip or the like on Windows) to UNZIP your file. Check that you got back the original. Congratulations! Your program correctly implements the same compression algorithm you have been using for years! Discuss in a sentence or two how good the compression was and why you think it was good or bad. <pre>
**TODO**: Answer this question
</pre><br>
- Now that you've played with Zip, we want you to do an **experiment** with Zip. Notice that there is a constant called `BUFFER_LENGTH` in `Zip.java`.
Higher values of this constant makes the compression algorithm that Zip uses use more memory and consequently more time. The "compression ratio"
of a file is the uncompressed size divided by the compressed size. Compare time, type of input file, and compression ratio by running
your code on various inputs. We would like an in-depth analysis. You should try at least one "book-like" file, at least one "website-like" file,
and some other input of your choice. We expect you to draw meaningful conclusions and possibly have graphs that convince us of your conclusions.
Say something about WHY you think you may have gotten the results you did.
This single question is worth almost as much as the implementation of `ArrayStack`; so, please take it seriously. If you spend less than 20 minutes
on this question, there is no conceivable way that you answered this question in the way we were intending.<pre>
### Zip Experiment ###
Now that you've played with Zip, we want you to do an **experiment** with Zip. <br>
Notice that there is a constant called `BUFFER_LENGTH` in `Zip.java`. Higher values of this constant makes the compression algorithm that Zip uses use more memory and consequently more time. The "compression ratio" of a file is the uncompressed size divided by the compressed size. <br>
Compare time, type of input file, and compression ratio by running your code on various inputs. We would like an in-depth analysis.
- You should try at least one "book-like" file, at least one "website-like" file, and some other input of your choice.
- You should also vary the `BUFFER_LENGTH` constant for each of these inputs.
- You should run multiple trials for each data point to help remove outliers.
We expect you to draw meaningful conclusions and have tables or graphs that convince us of your conclusions. In particular, you should explain WHY you think you may have gotten the results you did. <br>
This single question is worth almost as much as the implementation of `ArrayStack`; so, please take it seriously. If you spend less than 20 minutes on this question, there is no conceivable way that you answered this question in the way we were intending. <pre>
**TODO**: Answer this question
</pre><br>
#### Above and Beyond ####
- Did you do any Above and Beyond? Describe exactly what you
implemented.<pre>
----
## Above and Beyond ##
Did you do any Above and Beyond? Describe exactly what you implemented. <pre>
**TODO**: Answer this question
</pre><br>
Markdown is supported
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