CISC105, Fall 2004, Project 1a

The project 1 deadline is extended by one week.

There are some additional steps I want to add to the project to enable you to better test your program. Those steps are explained below.

I also want to call your attention to the ceil(), floor() and fmod() functions. These are very useful functions from the library <math.h> that may be useful to you in solving this problem. You can learn more about each of these by typing "man ceil", "man floor", and "man fmod" on strauss, and/or by asking about them in lecture.


Step 1: Changing the names of your input and output files

In your program, you probably have some code similar to the following:

infile = fopen("tons.txt","r");
...
outfile = fopen("costReport.txt", "w");

Note that this "hard codes" the names of the input and output files. It would be nice to be able to change these name without having to re-run the program.

We can do that by making the following changes to our program.

  1. Instead of int main(void), start your program with the following code:
    int main(int argc, char *argv[])
    {
    ...
    The parameter argc is the "argument count", and argv is the "argument vector". These are used to pass information into your program on the command line, as explained below.
  2. Put the following error checking code near the start of your program (before the calls to the fopen function.)
    if (argc<3)
    {
      fprintf(stderr,"Usage: %s inputfile outputfile", argv[0]);
      exit(-1);
    }
    
    This code checks to make sure that there are three things on the command line: the command to execute your program (e.g. "./proj1" or "./a.out") and the filename of your input and output file.
  3. Change the fopen calls to the following. (Note: infile and outfile are my FILE * variables; it's ok if your variables have different names, provided they are reasonable names.)
    infile = fopen(argv[1],"r");
    ...
    outfile = fopen(argv[2], "w");

What argv[1] and argv[2] represent is the names of files that you type on the command line when you run the program. For instance, you might type:

> ./proj1 tons.txt costReport.txt

and that would do the same thing your program does now. But you could also type:

> ./proj1 fredsData.txt fredReport.txt

and you'd run your program on data from the files "fredsData.txt", and produce output in a file called "fredReport.txt". This allows you to try out your program on lots of different data files, without having to rename each of those files to "tons.txt", or having to change your source code and recompile.

Step 2: The checker.c program

The checker.c program can be found in the proj1 subdirectory, along with a sample costReport.txt file. This program takes a costReport.txt type file as input, and determines whether any of the rules of the project have been violated, and whether the cost is computed correctly. It also determines the total cost for all of the tons listed in the input file.

You should copy this file into your directory, compile it, and run it on your costReport.txt file.

If you find that it reports any violations, note that it is possible that the problem is in my checker.c program, rather than in your program. So check that out. Did I make any logic errors in my checker.c program? Or is the logic error in your code?

If you think you have found a logic error in my code, let me know. The first person to correctly identify each logic error will earn a perfect score on the project. (Note that only logic errors dealing with the actual program logic count towards earning the perfect score prize. Pointing out errors with formatting, etc. is appreciated, but this will not earn you the "perfect score" prize.)

When you make your final script for the project, use the checker.c program to show that your output files are correct.

Step 3: Benchmarking your algorithm

How do you know if your algorithm is good enough?

The best way is try to convince yourself with mathematical arguments that your program uses an algorithm that produces the optimal solution. This is not always easy, but it is the best way.

Another way is to benchmark your solution against other folks' solutions. To that end, I will be posting some test files in the proj1 directory. Along with these test files, I will put the output of the instructor solutions, and the results of running those through the checker.c program. You can use these to benchmark your program and see how well it performs.

*** end of proj1a.html ***