Part 1: Coding Sorting Algorithms Implement a number of sorting algorithms, and then test their performance. This assignments consists of coding, and then testing the performance of your code using data sets of varying sizes (from small to large). Code these sorting algorithms in the template code provided under a4: Insertion Sort, Selection Sort, Merge Sort, Heap Sort, Quick Sort, and Bucket Sort. For Heap Sort you can use your implementation from assignment 3 (if it works). Check to make sure your sorting algorithms correctly sort lists of non-negative integers in ascending order (from small to large). Your algorithms only need to work with non-negative (>=0) integer values. You can write as many extra helper functions as you need. Please read the requirements for each sorting algorithm below. Since these algorithms are complicated and it is easy to make coding mistakes, JUnit tests in the form of assert statements are provided to ensure correctness. To verify the correctness of the sorting output, you should leave the assert statements in your submission and not comment them out or remove them. Part 2: Efficiency Testing After you have coded your sorting algorithms, you should find the runtime for each sorting algorithm. You will test each sorting algorithm on randomly generated input lists of sizes 100, 1000, 10000, and 100000. To determine the runtime of your sorting algorithm implementations, we use the System.currentTimeMillis() method, which returns the current time in milliseconds. We call System.currentTimeMillis() before and after a sorting algorithm runs, and subtract the two times to get the runtime estimate for a single sorting algorithm's run on one input array. The reported runtime may be affected by performance variability between runs, and we usually need to average the runtime over several runs. Calling System.currentTimeMillis() before and after the sorting will only give an accurate runtime estimate for very long input lists, since sorting a small array will generally take little time. We average the runtimes over three runs for each sorting algorithm and each input size. When the input array to your sorting is short (with sorting the dataset taking a few seconds) then System.currentTimeMillis() can be expected to give a less accurate runtime estimate. Part 3: Runtime reporting Upload a .docx or a .pdf file with a report including a table showing the average runtime for each sorting algorithm and input size. For example: Sort: Insertion Selection HeapSort MergeSort QuickSort BucketSort 100 1000 10000 100000 Worst-case O(n) O(n²) O(n logn) O(n logn) O(n²) O(n²) Avg-case O(n²) O(n²) O(n logn) O(n logn) O(n logn) Best-case O(n) O(n²) O(n logn) O(n logn) O(n logn) O(n+k) O(n+k) Stable Yes No No Yes No Yes Discuss your observations from this table. Which algorithm is fastest on the small vs. large datasets? Which algorithm do you expect to scale better with increasing input size? At the end of your report include the entire output of your run (copy and pasted).

Part 1: Coding Sorting Algorithms Implement a number of sorting algorithms, and then test their performance. This assignments consists of coding, and then testing the performance of your code using data sets of varying sizes (from small to large). Code these sorting algorithms in the template code provided under a4: Insertion Sort, Selection Sort, Merge Sort, Heap Sort, Quick Sort, and Bucket Sort. For Heap Sort you can use your implementation from assignment 3 (if it works). Check to make sure your sorting algorithms correctly sort lists of non-negative integers in ascending order (from small to large). Your algorithms only need to work with non-negative (>=0) integer values. You can write as many extra helper functions as you need. Please read the requirements for each sorting algorithm below. Since these algorithms are complicated and it is easy to make coding mistakes, JUnit tests in the form of assert statements are provided to ensure correctness. To verify the correctness of the sorting output, you should leave the assert statements in your submission and not comment them out or remove them. Part 2: Efficiency Testing After you have coded your sorting algorithms, you should find the runtime for each sorting algorithm. You will test each sorting algorithm on randomly generated input lists of sizes 100, 1000, 10000, and 100000. To determine the runtime of your sorting algorithm implementations, we use the System.currentTimeMillis() method, which returns the current time in milliseconds. We call System.currentTimeMillis() before and after a sorting algorithm runs, and subtract the two times to get the runtime estimate for a single sorting algorithm's run on one input array. The reported runtime may be affected by performance variability between runs, and we usually need to average the runtime over several runs. Calling System.currentTimeMillis() before and after the sorting will only give an accurate runtime estimate for very long input lists, since sorting a small array will generally take little time. We average the runtimes over three runs for each sorting algorithm and each input size. When the input array to your sorting is short (with sorting the dataset taking a few seconds) then System.currentTimeMillis() can be expected to give a less accurate runtime estimate. Part 3: Runtime reporting Upload a .docx or a .pdf file with a report including a table showing the average runtime for each sorting algorithm and input size. For example: Sort: Insertion Selection HeapSort MergeSort QuickSort BucketSort 100 1000 10000 100000 Worst-case O(n) O(n²) O(n logn) O(n logn) O(n²) O(n²) Avg-case O(n²) O(n²) O(n logn) O(n logn) O(n logn) Best-case O(n) O(n²) O(n logn) O(n logn) O(n logn) O(n+k) O(n+k) Stable Yes No No Yes No Yes Discuss your observations from this table. Which algorithm is fastest on the small vs. large datasets? Which algorithm do you expect to scale better with increasing input size? At the end of your report include the entire output of your run (copy and pasted).