In this lab we will read from another large data file. In this case, instead of students, we will be reading in courses from the file courses. Just as with students you'll need to make an appropriate class to hold the relevant information. Each line in this file contains information about a specific course -- its department, course number, scheduled meeting time, and capacity (maximum enrollment). Some lines continue with an equals sign (=) and another course number, indicating a course with which this course is cross-listed. The other (non-cross-listed) lines contain the course title and the name of the instructor.

When reading the file you will need to distinguish between the cases when the course is cross-listed and when it is not. This is easily accomplished by looking for the equals sign. When the course is not cross-listed you may just read the rest of the line in as one piece of text (bonus points for figuring out how to distinguish course names from faculty names).

The fields to read and store include the course, the time it meets, its maximum enrollment, and its name (which will actually include the professor). For cross-listed courses you will need to make a single record for both of its entries. This suggests you will need two additional fields in your class. One to signify that a class is or isn't cross-listed, and another for its other title.

As will normally be the case, you will need methods for the retrieval of all of the individual fields.

Note that as you read in the data, it essentially comes in sorted. The only problem is the cross-listed courses. Eventually you will want to use this class in a registration project, and at that time you will need to be sure that all students who register for AFR_S338 (for example) are being kept track of the same way. You will need a solution to this problem.

Although the data is essentially sorted already, it might also be useful to sort it by the name of the course as well (and then back to its original form). To do this you are to implement the merge sort algorithm. Your version of merge sort should be done with vectors. If you find it helpful to add a vector function for this purpose you may do so (please hand these in), but it should not be necessary. For the merge part of the merge sort you may use a temporary array while merging. Your merge sort method should take a parameter which specifies what type of sort to do (e.g. sort by name or sort by course ID).

Part III: Timing

One useful thing to do when studying complexity is to look at exactly how long programs and methods take to run. Java provides a handy method to do this. This method requires that your program have the following statement with its other import statements:

import java.util.*;

The method is called System.currentTimeMillis() and it returns a long which is the current time. So to time a method (in this case MergeSort) one might do the following:

long t1 = System.currentTimeMillis();

x.MergeSort(data);

long t2 = System.currentTimeMillis();

System.out.println("The time taken was "+ t2 - t1 +" milliseconds");

Use this timing ability to examine some basic questions about merge sort. Is there a qualitative difference in time between cases when the data is nearly sorted (or sorted) already and cases when the data is completely unsorted? What is the average time of the algorithm and how does it seem to vary according to how many items are sorted? Plan and run some experiments to test these ideas. A single run is NEVER enough to answer a question like this. Make sure you do enough runs to get reasonably supported answers.

When you are done you should have a program that reads in all of the data from the courses file and then allows the user to ask that it be sorted in one of two ways and to retrieve statistics on the sorting. As usual, you should give me a hard copy of all of your code and answers to the timing questions, as well as putting a copy of your folder into the drop box with the usual naming conventions.