General Exam Guidelines
(Last Mod: 27 November 2010 21:38:41 )
These guidelines apply to all exams in this course.
Bookmarks:
The exam will consist of a number of multiple choice or short answer questions followed by a few simple problem solving questions. As per the Course Policies, at least one half of the questions will come from the review material verbatim. The "review material" consists of the Review Sheets for that and all prior exams. Keep in mind that each Review Sheet generally includes additional material by reference.
You may be asked to write a flowchart to solve a particular task or write a flow chart that represents a particular fragment of code. Conversely, you may be asked to write a code fragment that implements a particular flowchart fragment. You may be asked to examine a flowchart or code fragment and evaluate what result it would produce. For the purposes of the exam, flowcharts and pseudocode are NOT interchangeable. If asked for pseudocode, you are to write pseudocode. If asked for a flowchart, you are to draw a flowchart. If the option is yours, that will be made clear in the problem statement.
Remember the basic rules about assumed variable types for single-letter and similar variable names (assumed by humans - not by the compiler, which always requires explicit type declarations). If the name starts with a letter from the end of the alphabet, it is a double. If it begins with a letter from the middle of the alphabet it is assumed to be an integer. In particular, if you use {u,v,w,x,y,z} in your work and don't indicate otherwise, we will assume it to be a double. If you use {i,j,k,l,m,n} and don't indicate type, we will assume it is an integer. Other than those twelve letters - you MUST tell us what type of variable it is. If you use one type, say an 'x1', and state that it is an integer then we will grade the problem as though it is an integer but may still take off minor points for style violations (unless the use of x1 - as opposed to k1 - is reasonable for the problem even though x1 is an integer)..
Statements, Code Fragments, and Complete Code
For many problems, you will be expected to write a statement, a code fragment, or a complete program/function. These are just differing levels of completeness. This will be unambiguously stated - you will be asked to "write a C statement that....", or "write a code fragment that...." or "write a complete function to...." or "write a complete C program that...." Be sure you understand the difference otherwise you will lose points for not providing complete code when it was asked for or waste time writing complete code when it wasn't asked for.
Do NOT spend the time writing a complete program unless specifically asked to do so. Keep in mind that the problems were written with the intention that they could be completely answered within about five minutes - ten at the most. Likewise, don't spend time writing a code fragment if the only thing that was asked for was a statement. A "statement" is a single line of code, although if you need a couple of lines to answer the question, that is fine.
Always: Regardless of which level of completeness you are asked for, you must always do the following (or lose points).
Statement: Just that - a single statement. You may write more than one statement (i.e., break it up) depending on how you YOU implement it. You don't need to write anything beyond the statement (other than the items you always need to include - see above).
For example, if asked to write a C statement that computes the base b logarithm of x, you might write:
#include <math.h> // log()
double x, y, b;
get x, b
y = log(x)/log(b);
Notice that we did not include 'y' in the "get" line. If we had, we would have been saying that 'y' needs to have a meaningful value in it and, since that value would have been lost when the last line was executed, you would have lost points because you obviously felt that you needed a piece of information that you then proceeded to throw away.
Notice also that the statement that actually answers the question is set off from the others (and we recommend you underline it). Also, it is the only one that has to be a statement with proper syntax. It is to your advantage to use proper syntax on all other lines that happen to be actual C statement, but the only one you will lose points for syntactical problems are the actual code statements that are asked for.
Fragment: A code fragment is an incomplete program/function containing only the information necessary to answer the question. In most respects, asking for a fragment as opposed to a statement merely means that the code is more complex than can reasonably be done in a single statement Therefore the same basic guidelines apply that did for statements.
For example, if asked to write a code fragment that computes the sum of the square roots of all the integers from one through ten, the following would be sufficient:
#include <math.h> // sqrt()double sum;
sum = 0;
for(i = 1; i<= 10; i++)
{
sum += sqrt( (double) i);
}
Notice, in particular, that we didn't use scanf() to get anything from the user and we didn't use printf() to print anything out. We weren't asked to do that. We were asked to compute a particular sum and that's what we did. Don't waste time writing a bunch of unasked for code.
Notice also that no main() declaration was included. It certainly could have, and doing so would allow you to indicate where the various statements in the fragment go relative to the function declaration, but you won't lose any points for not including them. What we are looking for is: do you know what steps need to be performed and what information you need in order to perform them?
Complete: Just that - complete. We should be able to type in exactly what you have written and then compile and run it (unless you are asked for a complete function in which case it is understood that we would need to provide a main() function to drive it. This is an example of where just indicating what header file is needed is not sufficient - you must include the correct #include directive.
For example, if asked to write a complete function called log_b() that takes two floating point arguments (of type double) and returns a floating point value (of type double) such that the return value is the logarithm of the first argument to the base of the second argument, you would need to write something like:
#include <math.h> // log()
double log_b(double x, double b)
{
return( log(x) / (log(b) );
}
Notice that we did not include any main(), we did not go ask the user for any values, we did not print out any thing. None of that was asked for. You won't lose points if you do, but you won't get extra points and it's a waste of time to write a big main() function that uses this function unless you are asked to do so. Now, if you go and include extra code like that within the function you were asked to write, you WILL lose points. The problem statement for the function said nothing about the function asking the user for input or printing anything out and you don't have the freedom to put this in there, just as the person that wrote the log() function didn't have that option.
Notice also that we named this function log_b(). This is for a simple reason - that's what we were told to name it. We do not have the option to choose to name it something else.
Reference Sheet (taken from the Course Policies page)
Reference information will be provided on the course website and this same information will be provided, in largely the same format, as part of the exam packet.. This Reference Sheet consists of the following items:
If, during the exam, you feel that you need a function not on the sheet merely ask the proctor and the prototype for the function will be written on the board.
What you may bring to the exam
Beyond a pencil/eraser (you are free to use a pen if you want), you are allowed to bring a calculator to the exam. However, you are restricted to using it for performing base-10 computations only. This means that if your calculator can perform hexadecimal arithmetic or number base conversions that you may not use those features to answer questions on the exam. As such, problems where non-base10 computation is required will not receive credit unless the intermediate work is shown.
You may ask any question you would like during the exam - but we are not obligated to answer it. In general, we will try to clear up confusion about what a question is asking for unless the confusion appears to be directly related to what the question is getting at. For instance, if asked to compute the base b logarithm of x and part of the point of the question is to determine whether you understand the basic principles of logarithms, we will not try to help you understand what is meant by the base b logarithm of x. Likewise, you are expected to know the syntax associated with all of the C statements and structures we have covered - questions about these will not be entertained.