Clarity, accuracy, and insight are the primary objectives
Clarity, accuracy, and insight are the primary objectives 
Assignment #1, due 2 October (Mike O'Donnell)
Execution demonstration (C. Donour Sizemore)
|
I'm confused by the requirement to 'demonstrate' the program on a series of inputs. Should I create a files which is the output of my shell session? Should I type up what inputs and outputs were used? Should I write a program to test my submission?You should present the demonstration in a form that maximizes clarity, accuracy, and insight, assuming that I basically trust you. It's a very bad idea to retype inputs and outputs, because you'll eventually make an error. Saving to a file is good lab technique, but sending me a separate file for each input and each output is going to really degrade clarity and insight. Probably the best thing to do is to cut & paste program, inputs, and outputs into a document that explains what happened. That document can be nicely formatted ASCII (reasonable line breaks, please), HTML, or PostScript generated by LaTeX or by your favorite word processor. With the interactive processors, it's generally a good idea to paste in a transcript of the interaction (leaving out any false steps that you corrected, of course). If you're real ambitious, you can figure out Donald Knuth's Web system for ``literate programming'' and use the commands tangle and weave. (Seriously, the Web system, which is not particularly related to the World Wide Web, is very cool, but you can't learn it in an hour).
Write a test program if it makes things easier, or if it promotes clarity/accuracy/insight. A test program is a great idea when there are a lot of test cases. That won't happen in this class. For your C(++) version, it might be handy to have a program with test cases encoded as data, and a little structure to feed those test cases to your procedure and output the result. Or, you can have a bit of extra structure to read test cases from standard input. For the other programs, where you use interactive interpreters, it's surely easier to type in (or cut & past from that file) the inputs. At this hour, if you're not already very familiar with some other technique, I recommend nicely formatted ASCII. Reminder: in the presentation of your program, make sure that the core code stands out very clearly from any extra stuff that you wrote to handle I/O and testing. And how will you know which of these I did?Make that clear in the text. Mostly, I trust you. It's also not hard to catch snow jobs, and it's very easy for me to cut and paste back into separate files and test things. Mike O'D. |
to: