This and all subsequent labs will be partnered assignments. We will assign partners for the first few labs, and then give you the opportunity to choose your partner.
You and your partner should work on all aspects of the project together: initial top-down design, incremental testing and debugging, and final stress testing and code review. There may be short periods of time where you each go off and implement some small part independently. However you should frequently come back together and talk through your changes. Partnerships where partners work mostly independently rarely work out well and rarely result in complete solutions. Partnerships where partners work side-by-side for all or most of the time tend to work out very well. Please make time in your schedule for your partner.
Treat your partner with respect and strive for an equitable partnership. By the end of the assignment you and your partner should each have a complete understanding of your joint solution.
Both you and your partner should:
On the CS system, cd into your cs31/labs subdirectory
$ cd ~/cs31/labsGet your Lab2 ssh-URL from the GitHub server for our class: CS31-s18
Clone a local copy of your shared repo in your private cs31/labs subdirectory:
$ git clone [your_Lab2_URL]You should have the following starter files in your repo:
$ cd [your_Lab2_URL]
$ ls
Makefile README.md floats2.txt floatsbig.txt readfile.h
QUESTIONNAIRE floats.txt floats3.txt readfile.c sorter.cFor more detailed instructions see the the Using git page. As you and your partner work on your joint solution, you will want to push and pull changes from the master repo into your local repo.
Your job is to write a program, sorter.c, that sorts floating point numbers. Your program should: read some unsorted floats in from a file, store them in an array, print some information about them to the user, sort them using the algorithm of your choice, and print them out in sorted order.
Your program will take one command line argument: the name of an input file containing a bunch of floats.
$ ./sorter floats.txt
floats.txt contains 10 floats, ranging from 0.00 to 9.00
The unsorted values are: 9.00 8.00 4.00 5.00 7.00 3.00 2.00 1.00 6.00 0.00
The sorted values are: 0.00 1.00 2.00 3.00 4.00 5.00 6.00 7.00 8.00 9.00
Here is an example of a valid input file for this program:
$ cat floats.txt
10 0.0 9.0
9.0
8.0
4.0
5.0
7.0
3.0
2.0
1.0
6.0
0.0The input file consists of a header line followed by one float on each line. The header contains the number of floats in the file (10) the minimum float (0.0) and the maximum float (9.0).
Makefile: This allows you to use make to compile your code and make clean to remove any executables.
readfile.h and readfile.c: These files contain a library for reading files.
sorter.c: The file into which you will add your solution. The starting point code includes a function, get_filename_from_commandline, that reads in the name of the file containing the floats. You should not change this function.
floats.txt, floats2.txt, floats3.txt, and floatsbig.txt: Input files provided to help you test your program. You should create other test files to more extensively test your program.
sorter.c is the only one of these files that you should modify.
We'll read input files using functions from the provided readfile library. readfile.h contains function prototypes for the readfile library. There are function comments in this file that describe each function and a high-level comment that describes how to use the library.
Here are the general rules for how to use these functions:
Open a file by calling open_file, passing in the name of the file to open as a string. The return value of open_file tells you whether or not the file was opened successfully--0 if the file is successfully opened, -1 if the file cannot be opened. You should always check the return value of this function and respond appropriately.
Call the read_int, read_string, read_float functions to read values from the file into your program's variables, where the name of the function you call determines the resulting type of the return value. Like open_file, these functions return 0 on success, and you should always check their return value. If you've reached the end of the file, they will return -1.
These functions take arguments much like scanf does: they need to know the address in memory where the value read in should be stored.
Close the file when you're done with it with close_file.
Your program's output should match the example output above. For full credit, your program should:
Store the set of floating point values only once (e.g., keep only one array, don't copy all the values to a second array). You may assume that there will never be more than 1000 values to sort, and you can use any sorting algorithm you like.
Exit gracefully if you detect an error that's not your code's fault (for example, if it was given the name of a file that doesn't exist). Be sure to check the return value from every function call that might result in an error.
Implement a helper function that takes the array and its size, checks to see if the array is in sorted order, and returns a value specifiying if it is sorted or not. This will be particularly useful for correctness testing of your sorting function on large input files.
It should be evident that you applied top-down design when constructing your submission. In addition to main(), you should have at least three non-trivial functions, each with a specific role.
Do not wrap lines in your C code files: all lines of code in your program should be less than 80 characters long (including white space characters). Hit return and continue the statement (nicely indented) on the next line.
Your code should be commented, modular, robust, and use meaningful variable and function names. This includes having a top-level comment that describes your program. Every function should include a brief description of its behavior, a description of its parameter values, and a description of its return values.
Your program should not use global variables. If a function needs a value from the calling function, then that value should be passed in as a parameter. If a function needs to store variables, then those should be declared as local variables inside the function.
The code you submit should have no "TODO" comments left in it. These are notes to you in the starting point code. You should replace them with actual code and/or comments.
Your code should compile cleanly with no errors or warnings and should not crash unexpectedly during execution.
The following is the suggested way to implement the lab and fulfill the requirements:
Read the floating point values in from the file and store them in an array.
Write a function that prints the contents of a float array. You'll use this function twice: once to print the original unsorted values, and later to print the sorted values.
Write a function that sorts an array of floating point values. It should sort the array in place; that is, it should not create a copy of the array.
Before you write any code, you and your partner should use top-down design to break your program into manageable pieces.
Implement and test your code in small increments. It's easier to find a bug when you've only added a few lines to a version of the code that ran without errors.
A function that uses an array usually needs the length of the array as a parameter. Unlike Python, C does NOT keep that information around (i.e., there is no len() function).
When printing floating point values, you can make the output more readable by limiting the number of digits that get printed after the decimal point. For example, using %.2f in the format string for printf() will limit the printed float to two digits after the decimal.
You can #define values that will never change in your program.
Use CNTRL-C to kill a running program stuck in an infinite loop.
Post on Piazza, attend ninja sessions, and/or come to office hours if you have questions!
To debug programs with command line options in gdb, include the command line arugments when you start the program with the gdb run command:
$ gdb ./sorter
(gdb) break main
(gdb) run floats.txtThere is a QUESTIONNAIRE file for you to fill out and submit with your lab solution.
Only one person in the partnership needs to git push your solution. It doesn't hurt if you both push, but the last pushed version before the due date is the one we will grade.
If git push fails, then there are likely local changes you haven't committed. Commit those first, then try pushing again:
$ git add sorter.c
$ git add QUESTIONNAIRE
$ git commit -m "Finished lab"
$ git pushThe push will also fail if your partner pushed, but you have not pulled their changes. Do a git pull. Run make and test that your code still works. Then you can add, commit, and push. If this doesn't work, take a look at the "Troubleshooting" section of the Using git page. You may need to do a merge. After the merge, test that your code still works before submitting.