In Programming 1 we will have programming exercises as homework every week. You'll submit your solutions to these exercises to ReCodEx, a system that evaluates and scores your solutions automatically.
When you upload a program, ReCodEx compiles it and runs it against a number of test cases. Each test case consists of a certain input that will be sent to your program, plus the output that is expected in response to that input. Your score for the exercise is determined by the fraction of test cases that your program passes. If you submit a program and it earns less than this maximum, you may fix your program and submit again.
To test the efficiency of your solutions, each test case includes limits for the amount of memory and execution time that your program is allowed to use. To pass a test case, your program must
produce the correct output
not take too long to run
not use too much memory
not crash, exit with an unhandled exception, or return an error code to the operating system
Here is some general advice for submitting programs to ReCodEx.
Each exercise's description includes at least one sample input and expected output. Be sure to test your program on this sample input on your own machine! It is wisest to test your program on a variety of inputs before you upload it to ReCodEx.
Your program must produce exactly the output that ReCodEx expects, with no extra verbiage. For example, if ReCodEx expects the answer "7" on a single line and you output "x = 7", the test case will fail. Similarly, do not print any input prompts; ReCodEx does not expect them. (ReCodEx will, however, generally ignore trailing spaces on any output line.)
For most exercises, your output lines must appear in a certain order, but in some exercises they may appear in any order. If that is the case, the exercise description will say so.
ReCodEx does not care when your program writes its output. Sometimes students think that their program must first read all its input and only write the output after that, but it doesn't work that way. In many cases it's easier to write a program that writes the output continuously, as it processes each input item.
If your submission does not pass all the test cases on the first attempt, do not despair! The test cases are often designed to test edge cases and unusual inputs, and will often test your program on large input values or with large amounts of input data. So your program may be largely correct but still fail several test cases.
If your score is less than the maximum, look at the test results in the lower-right-hand corner of the window. They will look something like this:
Each row represents one test case. The columns represent, in order:
overall score
correctness of the result
memory utilization
execution time
exit code
(You can mouse over the icons at the top to remind of you each column's meaning.)
Look at what went wrong. Here are the most common problems:
If you see a red X in the execution time column (with a runner at the top) for some tests, your program is too slow. It has exceeded the allowable execution time for these tests. You'll need to make your program more efficient to pass these tests.
If the execution time shows a green checkmark, but the correctness column under the scales) shows FAILED for some tests, the your program is fast enough but produced the wrong answer for those tests. Think about possible cases where your program could produce an incorrect result. Try different inputs when running the program on your own machine, and look at your code again to see if there are possible bugs or unhandled edge cases.
If you are convinced that your program is correct and you are baffled as to why some test cases are failing, you may email me to ask for a hint. Of course, I may not always be available shortly before the deadline. For that and other reasons, I recommend starting early on these exercises every week. Some exercises may be challenging, and it may take some time to think about each exercise and come up with a complete working solution.