CSCI P415/P515 Homework

CSCI P545 Computer Science Department Indiana University

Wed Feb 20 14:54:31 EST 2008 © [SDJ]

§P415 Homework Assignment

Part A

Write a program to reverse the contents of an array. Use whatever programming language you want. In addition to working data, your subdirectory must include these two files at top level:

A self-contained, executable object named dut.
(Optional for P415) A document named report.pdf

Program Requirements (`dut`)

Input: dut takes input from stdin, which must contains no more than 100,000 non-negative integers seperated by new-lines and and nothing else. These numbers are in the range from 0 to 2¹⁶-1; that is, representable in a 16-bit word.
Output: Write to stdout in the same format, new-line separated non-negative integers in reverse order from the input.
You need not (and should not) assume that your program must be sensitive to "white space", invalid or extraneous characters, etc.

test-in test-out

1 2 3 4 5

–dut–>

5 4 3 2 1

For example, I might write a C program file called dut.c and compile with

% gcc -o dut dut.c

to obtain executable object, dut. To test this program, I'll create an ASCII file test-in.txt containing the characters: "1•2•3•4•5•" (`•' stands for the Unix new-line character, so this file would display as depicted to the right). If I invoke dut with the command:

% dut < test-in.txt > test-out.txt

The result should be a text file test-out.txt containing "5•4•3•2•1•" It is important to implement this program exactly as specified because, in the second part of this assignment, other students will be "black-box testing" your dut using their own input and output files.

Instructions for Part A:

In your working directory, design, implement and test your program. Name the resulting executable file dut.
(Optional for P415) Keep a written journal of your design activities, paying particular attention to your thinking, "design process", including a systematic testing procedure.
Include all testing files, scripts, etc., used during development.
(Optional for P415) Include at the top level of your directory a document named report.pdf, summarizing your journal.

Part B

In the second part of this assignment, you will be given some number of executables to test. You will not be provided source code or documentation. The designs under test (duts) are a "black boxes" to be verified by execution on the your test-input files and observing the results.

In testing, your primary focus is correct execution of the dut. So at a minimum you must document the results of your functional testing.

However, you should also pay attention to performance questions, (size, speed, etc.). In particular, try to estimate time-of-execution as a function of input-file size.

Instructions for Part B:

All testing, results and documentation are to be included in your working directory. More details will be provided later.

Grading

Part A. A significant portion of the credit for Part A is based on the clarity and quality of your written report.
Part B. Ammend your report to include the results of your tests.
- If your testing exposes an error in another student's dut program, N (value yet to be determined) points are added to your score and N points are subtracted from the implementor's score.
- If your claim of an error subsequently proves to be wrong, 2N points are subtracted from your score and added to that of the innocent party.
- If a disputed error is shown to be the result of an specification inconsistency, your score(s) will be restored and bonus credit (depending on the judgement of the Instructor) given to both parties, provided they present a better problem specification.

Notes and Hints:

The intended goal of Part A is to design and implement and array reversing program. As the course progresses, we will look at list- and then array-reversal algorighms. To get the most from this assignment, you should develop a program that reads input into an array, reverses the content of the array, and then writes it to output. However, since you are turning in a "black box", there will be no way (except possibly disassembling) for the tester to see how you implemented your solution.
A tester may be able indirectly infer how your program works by measuring performance, (running times, size, etc.), and they are encouraged to make these estimates. But correctness is the primary concern.