Exam I Results:
mean = 73.21 (including +15% bias)
st. dev. = 15.46
lowest = 35%
highest = 103%
Note: the grade on p. 2 of your exam already includes the 15%.
I will post the answer key on the schedule page.
(I will answer specific questions on Thursday, 3/18).
Structures (and Classes) and Functions:
Good software engineering depends on clean interfaces.
We should know what's going into a module and what's coming out of a module.
(A module is any well-defined part of a program. In C++ that usually means a
class, structure, or function.)
Pure Functions: are like mathematical functions (e.g., sin, cos, log, exp, +, -, ...).
They are "mappings" from some inputs to some outputs.
In programming terms they have input parameters and they return a value. E.g., in
y = sin x the only input is x, and the only output is the value of sin x. E.g., in y =
log (b, x) the only inputs are b and x, and the only output is the value of log (b, x).
These are called pure functions because the only inputs and outputs are through
the parameters and the returned value. The interfaces are very clear.
int F (double x, double y) {
....
return .... ;
}
Impure functions have "hidden" (non-obvious) inputs and outputs.
Example, using or assigning to a global (non-local) variable.
double x, y;
int F (int A, int B) {
...
x = y * 2; // using the variable y and assigning to x
// this mean y is a hidden input to F
// and x is a hidden output from F
...
return A + B - y; // result depends on hidden input
}
It is harder to understand the effects of executing this function because it has
hidden inputs and outputs. These are generally called "side-effects."
Bottom line: impure functions are not always bad, but they're treacherous, and so
you should avoid them whenever you can.
There are some programming languages (such as functional languages), which only
permit pure functions.
You want your functions to be easy and reliable to use.
We also talked previously about values and objects.
Values are like mathematical values (numbers, sets, etc.) that you operate on to
produce other values. E.g., 3 + 5 operates on the values 3 and 5 to produce the
value 8.
Objects are more like real-world objects, with properties and behaviors. We ask
objects to do things to themselves or to other objects. E.g., robot.forward(1.0);
asks the object robot to execute a certain behavior (go forward). E.g.,
NewHire.hireDate.print(); asks NewHire to print its hireDate.
Sometimes it's obvious whether something should be a value or an object, but
sometimes it's not. It's a matter of style.
E.g., Time (in the book example) could be treated as a value or an object. (I would
be inclined to treat it like a value.)
When we compare times, we do it with T1.after(T2). So we are invoking the after()
member function in the object T1 and passing it the object T2. So this means
after() will have implicit access to the member variables of T1, but will have to
access the member variables of T2 explicitly. T1.after(T2) calls the after() function
"inside" T1, and so it has implicit access to T1's members.
Consider T1.add(T2) this invokes add() in T1. It has implicit access to the members
of T1, but has to access the members of T2 explicitly.