Commit 9414e4f2 authored by Ruth Anderson's avatar Ruth Anderson
Browse files

Merge branch 'writeup_changes' into 'master'

Updates P1 Write-Up for 18au

See merge request !1
parents f510df12 d245b01c
Pipeline #140783 failed with stage
in 0 seconds
# 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>
### 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>
- Did you enjoy the project? Why or why not?<pre>
- Did you enjoy the project? Why or why not? <pre>
**TODO**: Answer this question
</pre><br>
- 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? Why don't we do this in general?
In other words, what about fixed-sized FIFO worklists makes peek(i) make sense? Why does peek(i) NOT make sense in other worklist implementations?
**You should consider only the interface**, NOT the underlying implementation of our FixedSizeFIFOWorkList. <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 ##
For this part of the write-up:
- You'll need a working SuffixTrie to run the ZIP experiments for this writeup. Implementing SuffixTrie yourself is part of the Above & Beyond section and not required for full credit. To use our provided SuffixTrie.jar (if you don't want to implement it yourself), right click on SuffixTrie.java in the Eclipse sidebar, choose Refactor > Rename, and name it something else (like SuffixTrieUnused.java) **with "update references" unchecked**. <br>
- Put your test files in the root directory of the project (that is, **at the same level as src**, not in the src folder).
### 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