CPSC 035: Lab 4: MergeSort and Big-O

Due on Wednesday, October 7th (by the end of the day, U.S. Eastern Daylight Time).

Preliminaries: Collaborating With Your Partner

This is the first partnered assignment of the semester. You will work with a partner to complete this lab. Collaboration is a necessary skill in modern Computer Science: large applications require thousands of developers to work together. Team labs will give you the opportunity to practice this skill as well as give you someone to work with to solve the challenges you’ll encounter in lab assignments.

You are encouraged to use whatever tools and practices that you and your partner can agree upon to complete your work. That said, a comfortable work environment is a must for productivity. We are strongly recommending that you use Visual Studio Code’s Live Share plugin to work together. This will allow you both to edit the code for your lab assignments simultaneously! We have prepared a Live Share Tutorial to help you set up this tool.

You can use Git to work seamlessly on your code. If one partner runs git push to send their changes to GitHub, the other can run git pull to receive those changes. We encourage you to take turns hosting your sessions when you work on the lab together. It’s important that both partners participate in completing the lab.

Make sure that you and your partner have reached an agreement about how you will work together before proceeding. When working with your partner, we expect you to be polite, to keep an open mind, and to make sure that you do an even share of the work: not too much and not too little. We expect your partner to afford you the same courtesy. We hope everyone’s partnerships will be positive experiences. If you have any trouble with your partnership, however, please reach out to your lab instructor or professor and let us know.

Lab Assignment Overview

This lab consists of three primary parts:

  • Implementing and testing the MergeSort algorithm

  • Proving the Big-O complexity of mathematical functions

  • Analyzing and empirically testing algorithms to understand complexity

As you will be working with another student to complete this lab, you will both use the same GitHub repository. The URL for your repository will be

git@github.swarthmore.edu:cs35-f20/lab04-<your-teamname>

where your-teamname has been selected at random. You should be able to find your team repository by visiting the course organization on GitHub.

Please remember that both lab partners must learn this material; it will feature prominently on your tests and final exam. Do not divide up this lab e.g. to give one team member the theory material and another member the sorting algorithm. You should be working on all parts together.

Part I: MergeSort

Your starting repository includes the following files:

  • mergeSort.h/mergeSort.cpp: The library for your MergeSort algorithm.

  • sortArgs.cpp: A small program to use your algorithm to sort command-line arguments.

  • tests.cpp: A file where you will write your unit tests.

  • Makefile: The file make uses to understand how to build your project.

Files that you will need to modify are bold.

To complete this lab, you should implement the mergeSort function in mergeSort.cpp just as we discussed in class. You’ll need to be careful to follow the algorithm closely and to manipulate array indices accurately. You’ll probably have bugs in your first attempt, so remember the following tools we have discussed for finding and correcting mistakes:

  • valgrind, the program that helps you find memory errors

  • UnitTest++, the unit testing framework (which you are required to use)

Unit Tests

For this lab, you will be graded not only on whether your mergeSort implementation is correct but also on whether you have properly tested it. You have been provided a couple tests to start, but you are required to write at least four more tests that investigate different aspects of sorting. Some ideas for additional tests include:

  • Sorting a single-element array to make sure nothing bad happens.

  • Sorting an array that is already in order and seeing whether it stays that way.

  • Sorting a large array of numbers that approach a midpoint from opposite directions (e.g. [0,999,1,998,2,997,…​]).

  • Sorting an array in reverse order and seeing whether it winds up sorted.

  • Sorting an array that contains several duplicates to make sure that they are handled properly.

Although you have a minimum number of tests to write, you should ideally write as many as it takes for you to be confident in your code. Remember: each time you change your tests, run make tests before re-running your ./tests program.

Coding Style Requirements

As usual, you will also be required to observe good coding practices:

  • Your C++ code must have proper and consistent indentations.

  • You must have proper and consistent usage of spacing & braces for if, else, for, and while conditions as well as class definitions and code blocks.

Part II: Written Assignment

In this part of your lab, you will apply the Big-O complexity material that we have discussed in class by writing some Big-O proofs about mathematical functions.

Electronic Submissions Only

In order to complete this assignment, you will need to produce a document containing some mathematical expressions and figures. You will commit and push this document to your GitHub repository; the document may take the following forms:

  • A PDF file named WrittenLab.pdf containing formatted text

  • A file named WrittenLab.tex containing formatted text

Your team must submit the document electronically in one of these forms. In particular, you are not permitted to turn in the following (to name a few examples):

  • A raw text document (regardless of formatting)

  • A scan of a written document (even if the scanned document is a PDF)

  • A Microsoft Word file or similar word processor document (although you may write the homework in that format and then export a PDF from it)

  • A piece of paper turned in by hand

A Few Words About LaTeX

LaTeX (pronounced lah-tek or lay-tek) is a document preparation system frequently used to produce conference papers, dissertations, and other academic works (in addition to other material). With LaTeX, you code your document much as you would an HTML document or a Python program. For instance, the LaTeX code

I'm \textit{not} making this up: \(e^{i\pi} = -1\)

produces

You are not required to learn LaTeX for this course. However, it may be easier to use basic LaTeX to complete your homework than to use something like Microsoft Word’s equation editor. In case you’re interested, the following files are already part of your repository:

  • LearningLaTeX.tex: A LaTeX document with some examples of how to use LaTeX to write the things you need to write in this lab. You should look at the .tex file before looking at the .pdf it produces.

  • WrittenLab.tex: A LaTeX document containing your homework problems and places for you to fill them in. These same problems are listed below, but they have been included in this document for your convenience.

Big-O Proofs

Use the formal definition of Big-O notation to prove the following statements:

  1. \(2n^2+5\) is \(O(n^2)\).

  2. \(n^4-3n^3+8n^2\) is \(O(n^4)\).

Part III: Mystery Functions

In this part of the lab, you will first analyze six simple loop structures and determine their runtime complexity in terms of Big-\(O\) notation. Then, using the provided program function_timer, you will graph the empirical runtimes of a these functions in a mixed up order. Your job will be to match your theoretical analysis to the empirical data.

Functions

Begin by identifying the Big-\(O\) runtime for each of the following functions. Provide a brief justification of your answer; a sentence or two should do. Give the strictest Big-\(O\) you can find: don’t give \(O(2^n)\) if the function is also \(O(n)\) and leave out any unnecessary terms (give \(O(n^2)\) rather than \(O(n^2+3)\)).

  • Function fnA(n):
        For i In 1 To n/2:
            Set a To i
        EndFor
    EndFunction
  • Function fnB(n):
        For i In 1 to n:
            For j In 1 to n:
                Set a To i
            EndFor
        EndFor
    EndFunction
  • Function fnC(n):
        For i In 1 To n:
            For j In 1 To 4:
                Set a To i
            EndFor
        EndFor
    EndFunction
  • Function fnD(n):
        Set i To 0
        While i < n*n*n:
            Set i To i + 1
        EndWhile
    EndFunction
  • Function fnE(n):
        For i In 1 to n:
            Set j To 1
            While j < n:
                Set j To j*2
            EndWhile
        EndFor
    EndFunction
  • Function fnF(n):
        For i In 1 to n*n:
            For j In 1 to n*n:
                Set a To j
            EndFor
        EndFor
    EndFunction

Using function_timer to Inspect the Functions

Each of the above functions has been implemented and packaged into an executable function_timer that was provided to you in your repository for this lab. The function_timer program will provide empirical runtime data for each function in a form that can be graphed by another tool called gnuplot.

To use this program, you must pick the following:

  • Which function(s) to plot. For each function, you must provide a command-line argument in the form -2, -3, etc.

  • The minimum and maximum values for \(n\). Remember: for slow algorithms, \(n\) should be small or the program may take a very long time. For fast algorithms, you’ll need to give a very large \(n\) or you won’t be able to see anything meaningful on the plot. Start with small \(n\) for each function and work your way up.

  • The name of the file to create.

For instance, suppose we wanted to graph functions 2 and 3 within \(10 \leq n \leq 100\). We can save this to any file we want; let’s pick “funs 2 and 3 from 10 to 100.png”. Then we can run the following command:

./function_timer -2 -3 -n 10 -m 100 -s "funs 2 and 3 from 10 to 100.png" | gnuplot

If you get a Permission denied error when trying to run the above command, then do: chmod u+x function_timer to make this program executable, and re-try the command.

If everything goes well, you won’t get any output. Instead, the file will be created (or updated) and you can take a look at it by opening it in your file browser. The image will look something like this:

Plot example for functions 2 and 3 between n=10 and n=100

Note that this image is an example and will not be what you actually get when you run the same command. Also note the "pipe" character (|) in the command above; this feeds the output of function_timer to the input of gnuplot so it can graph the results for you.

Written Response

For this part of the assignment, include in WrittenLab.pdf the following parts:

  1. A description of which mystery function (1, 2, etc.) matches which algorithm (fnA, fnB, etc.).

  2. For each mystery function, a short paragraph describing why you think it matches the algorithm you named.

  3. For two of the mystery functions, a graph (saved from function_timer) that supports your claims.

Summary of Requirements

You must

  • Implement and test MergeSort

  • Provide a PDF or LaTeX file containing the following:

    • Proofs of the Big-O complexity of the functions described above

    • A Big-O analysis of the pseudocode algorithms given above

    • A matching of these algorithms to mystery functions using function_timer

  • Each student must complete the lab assignment survey as part of the participation grade.