Instructions for Laboratory #2 Assignment -- COM1201 Sp2000 -- Professor Futrelle

The lab is Wednesday, April 26th and due on Tuesday, May 2nd, at the beginning of class.

This first explains the general goals of the lab, then the specifics, and finally the mechanics of just what needs to be handed in. These project files will be made available to you before the lab is given, so you can get a head start.

Here are some last-minute details (4/25/2000) about setting up your project and getting the source file downloaded cleanly and renamed properly.

• Because of the differences between Unix and Windows line terminators, one way to successfully download the source file lab2.text to a PC is to use Internet Explorer and save the file not as text but as an htm file (one of your choices). Then you need to rename it with a .cpp extension. But if you don't do this carefully in Windows Explorer, you'll end up with a file with two extensions, not what you want. Under View, go to Folder Options and then choose the View tab. Turn off "Hide file extensions for know file types". Then you will see all the extensions and when you rename the file you'll be able to specify exactly what the file name and extension are. When you do this properly and open the file in VC++, it will not have an extra blank line between every line. The same considerations apply to downloading the medrecordbase file.
• In setting up your project, choose a high level folder for its Location. Then a folder will be created for you that has your project name. Put a date in the name or an "A" or "B" suffix so you can't keep track, if you create more than one before you get everything working.
• Just putting the .cpp file into your project folder isn't enough. You must go to the Project menu and Add to Project and then Files to add it.
• Remember that this project does not use any core tools so it should be do-able on any PC with Visual C++. However, it is your responsibility to make sure that your finished project runs on our CCS NT machines.

The general goals are for you to:

• Understand key-based sorting of records.
• Use "Metadata" to describe your data file.
• Understand sorting problems such as stability.
• Build a simple "vanilla" application in C++.
• Decompose a project into appropriate files.
• Organize your project so the code and results are clear and clearly explained.
• Have a chance to design your own data records and adapt working code to deal with them.

More specifically, you are to do the following:

1. Design the records you want to use. It would be a good idea to do this in advance. Every student in the class must use a distinct record design.
2. Build and run a simple console project using the code that I have written. Be sure to have the medrecordbase.dat file in the same folder as your project and source code. See the Lab2 web pages for more on how to do this.
3. Start modifying my code by adding your class and adding the various reading and printing functions for your classes. My code can be downloaded from this lab web site. Change the .text extension of the code to .cpp to use it. By choosing slightly different names, you can do the additions without having to delete anything that I wrote, so you can keep them around for reference. When you're all done and everything works, you can delete my classes and functions from the source file (.cpp) file to clean it up. Of course you can toss my stuff earlier if you want; it's up to you.
4. You should design and carry out a systematic set of tests. I'd suggest something like the following.
   • Use a data file with short strings and numbers for easy print-out for testing.
   • Show that the sort works on at least two distinct fields, one a number and the other a string.
   • Sort a set of records twice, by two different fields to check stability. Be sure to design records that will sort differently by a stable versus an unstable sort. See the note on stable sorts below.
   • Write the sorted records to files, along with a metadata line that explains what field the sort was based on and whether it represents a second sort of the same sequence.
   • Once things are working well, create a new version of your project with three files: One header file, one file of definitions, and one client file with main().
   • Grab your input and output data for pasting into your writeup.
5. Comment your code. Some comments should be grouped before a class or function, others might be at the detailed code level. Please don't put one comment for every line of code. Use better judgement than that.
6. Work on the documentation of your project, which should include what you did, how you did it, what your results were, and most importantly a discussion of your results, and conclusions. Results don't "speak for themselves"; they must be explained to be worth anything.

Some of the logistical details:

• Build your project and files and work only on the hard disk. Floppies are for backup only. You should never be actively editing or otherwise using files that are on floppies.
• Work with a pair of labeled floppies. Hand in one and keep one.
• It's most important to back up source and data files. Back up everything but the Debug folder (which is quite large and will be regenerated by the IDE).
• Collaboration: You're more than welcome to work with other people on your project, BUT: The work you hand in must be distinct from the work that anyone else hands in. The function names, variable names, comments, input data, record design, etc. must all be different. What you can collaborate on is ideas and strategies, debugging, questions of C++ syntax and style, etc. You can have another student read your code or writeup and critique it, giving you general suggestions as to how it might be improved. Collaboration should not be closer than that just described. Every quarter, a few students get zeroes (big "oh's") for overstepping the bounds and not doing their own work. Let's cut that number of students to zero in this course.

What to hand in. (Keep this in mind as you work on your project.)

• I will give you manilla envelopes in which to put your floppy and hardcopies.
• Your floppy should have all your project files, source files, and data files -- everything but the Debug folder and its files.
• Hand in hardcopies of source code listings for all ".h", ".cpp" and .dat files.
• Hand in a writeup that includes, as appendices, your input data and output demonstrating the sorting you did. You may need to add comments to these to make them clear. Of course all data includes a metadata line. That can help. Your writeup can be partially written early on, well before it's due. Writing parts of it early can often help guide your work.
• Hand in whatever you have finished at the beginning of class. To make sure you succeed in this, print out earlier versions of your code and writeup from a few days earlier or from your work Tuesday morning, at the latest. Please do not come to class with nothing and an explanation (excuse) that the printer didn't work or you lost your files. Print some things out early so we'll know that you were getting work done.
• If you can't complete your project by the deadline, or even if it won't compile, hand in what you have gotten done by the beginning of class. Then you'll get some credit for that with no late points deducted.
• You can continue to work on your project after Tuesday if you're having serious problems, but again, turn in what you have up to that point on Tuesday.
• And of course, ask Ms. Zheng or me or the tutors for help. Ask early, not at the last minute.

Stable and Unstable Sorting

Sedgewick explains this concept rather well on page 271. The major point to understand is in a stable sort, if a set of records is sorted by key A and then the resulting file is sorted by key B, every set of records with the same value of B will sort together and the A records in that set will retain their original order. For example if my medical records file had some of the age values the same in different records and a stable sorting algorithm was used then the following would happen: If the file was first sorted by names, they would be in alphabetical order. If the resulting file was sorted by age then it would have a set of records of equal ages, e.g., each 15 months, grouped together, but the records with age 15 would retain the previously sorted order for the names.

Good Luck and enjoy the project!