Hey - in Part 3 the math you did doesn't work out right!
Okay you caught me. In fact in the FIRST PART of Part 3 I previously
showed the "Total Cost" as being 23.04. In fact the "Total Cost" should be
29.91. This Total Cost is computed by the use of 17.2 gallons at $1.739
per gallon. Of course the "Cost per mile" now changes too - to 0.075.
Does the output produced by our programs have
to exactly match the output shown in the handout?
Yes, your output should match our output exactly. No ifs, ands,
or buts. Now, having said that, how you actually make your output
look the same as ours is up to you. That is, if you use combine tab
characters, spaces, and field widths in a way different from what
we did, that's fine with us.
How do I figure out the output spacing?
In
the output for Part 1, there are 6 spaces between "discount:"
and the 764.24 Given that, it's easy to figure out the rest of the spacing for
that part.
In
the output for Part 2, there are 10 spaces between the "textbook:"
and the 49.95. In addition, the top heading line is:
"Texts", 6 spaces, "List", 9 spaces, "Discount", 10 spaces,
"Sales", 11 spaces, and then "Final".
In
the final output for Part 3, there are 4 spaces between the
"Gas gallons purchased:" and the 17.2.
The
output for Part 4
has the same spacing as the output for the third part.
How do I go about getting the output
to line up correctly?
Assignment #2
gives you example output and the previous question
gives you details on the spacing. One way to figure out exactly
how to do the output is to make a little chart that shows how
the various output values relate to the tab positions. For
example, for this output fragment:
Videos List Discount Sales Final
Bought Price Price Tax Price
1 8.95 7.88 0.32 8.19
2 17.90 15.75 0.63 16.38
we can make a chart that looks like this, where the T's
represent the positions of tabs and the xxxx.xx's represent
fields that start on the tab position, are large enough to hold
the numbers being placed in that column, and that line up with the
output above:
123456789.123456789.123456789.123456789.123456789.123456789.1234
T T T T T T T
Videos List Discount Sales Final
Bought Price Price Tax Price
x xxxx.xx xxxxx.xx xxxx.xx xxxx.xx
x xxxx.xx xxxxx.xx xxxx.xx xxxx.xx
Once you have this chart, it's relatively straightforward to generate
the printf's to produce the appropriate output.
Do we have to prompt for input?
No, in fact we specifically do not want you to write a prompt
before reading the input (that is, just read the miles driven
and gallons purchased without printing a message asking the
user to enter them). While this makes your program a little
confusing to use, it happens to makes life easier for our
automated grading program.
Do I have to indent my programs
exactly like the examples in class?
Yes and no. You can't go wrong making your programs look
like the ones in the textbook, since these programs are designed
to be as readable as possible. But we allow you some flexibility
to be different.
Here are some style
guidelines for writing C programs
detail exactly what we expect your programs to look like.
On the last part, do we have to read all
of the user's input first and then produce the output?
No. But admittedly the
original input/output description
for the last part of this assignment for this assignment is
confusing. The idea is that you read a pair of input values, then produce
the output for those values, then read the next pair, then produce
their output, and so on.
The handout was simply showing all the input the user typed and all
that output that resulted. This has been updated in the assignment
handout online - take a look at the longer comment there.
Can we assume "miles driven" will always be an
integer?
No.
Is there supposed to be a space before
the colons in the output?
No.
Can we assume the user is well-behaved?
Yes. Assume that the user will enter any input exactly the way
we expect. In future assignments, you'll have to relax that assumption
and print error messages when the user does something wrong.
What do you mean by "our results must be exactly
the same"?
We mean that your results must be identical, in terms of the characters
in the various messages the program prints, the number of spaces between
the columns, everything.
Can we turn in things in before the due date, see our results,
and then have a chance to fix them and turn them in again?
Unfortunately, that would require new software. We have no mechanism
to automatically run your programs immediately when you turn them in,
even though that would be ideal.
However, as a compromise, we are making available sample runs of
our solutions. Follow the links below to see the exact output files
created when we run our programs (or transcripts that show both the
input we gave the programs and the resulting output).
To verify your solutions are correct, you can do the following.
If your program doesn't require input, simply run it, saving its output
into a file, which you can do with the command:
your-program >
your-program.output
(That's a greater-than sign after your-program).
Then, you need to save our output into a file (which you can do by
following the
link to it above and then using whatever mechanism your browser provides
for saving files).
Once you have your output in one file and our output in another file,
you can use the diff command to verify that they are the same.
If you've called
the output from our solution our-solution.output, then if
diff your-program.output our-solution.output
produces no output, your program's output is exactly the same as ours.
Otherwise diff will give you some information about which lines
in the output differ, which will help you track down the problem.
For programs that produce input, things are a little trickier. What
you can do is run the script command to produce a transcript of
your run and then compare that transcript with the transcript of our
running our programs. You run the script command like this:
script your-program.scr
It'll print a message, then a "wiliki" prompt. At the prompt you run
your program and provide whatever input you want to provide. When your
program finishes, you then type
exit
to complete the script. Now the file your-program.scr
will contain a complete session of your input and output. You can then
use the diff command on the script files to compare your
run with our run. There should now be
some differences in diff's output, but these will involve the
lines where you saw the "wiliki" prompt and the date and time the script
was created.
