Score Calculation and Distribution with Comparison to Previous Class

After grading the homework I published on the course web page on Friday the total points earned by summing the 30 pts from the midterm and the 40 pts from the homework submitted. These numbers and the percentage of the 70 pts that they represent along with the equivalent letter grade are in the right three columns of the first table. I decided to scale the midterm scores by adding 24 points to every raw score, thus bringing the midterm average to 70. I then determined that rather than fail anyone, I would raise the actual base to the level so that the lowest grade would be a D. This raised the published base to the actual base values. Since I put 132 points on the final, one could earn nearly 40 points if you knew all that was quizzed, but in my other class the maximum had been 99. I also determined to give a bonus to those who made improvement between midterm and final exams. When the raw scores on the final were obtained, I raised all of them by 14 points so that the final average for the class was 70%, then I added in 50% of the improvement between the scaled midterm and the scaled final (three people went down). I then took the % of 30 points that were missing and added the final’s contribution to the actual base to get the total grade points in the class. The middle two columns compare what raw score was needed on the final to keep or improve the BEFORE FINAL grade to the actual raw score earned on the final. In only one case was that goal attained, but two additional students (including the F by design) improved their grades anyway because of the scaling of the final score and the improvement bonus. On the other hand, five students lost a grade because of the final not validating what their homework score pretended, and two students didn’t change their position.

The second table compares the raw scores on the final between the two classes and associates with each the number of java coding assignments submitted. The four colors represent the course grade earned in each of the classes (A-D). As was the case at midterm, the data clearly points to an association between homework done and the score on the final (although one of our students did very well on the final without submitting any assignments for three months). Although I had intended to grade every correctly submitted assignment 1.6 points and incomplete or erroneous assignments 0, I ended up counting partially correct assignments half and scaling all of the scores to the maximum 20.5 scored by the high student (in the other class three students got a bonus by exceeding the expected homework maximum).

	total grade pts	% of 30 earned on final with bonus	raw scored of 132	raw needed of 132	actual base	published	BEFORE FINAL
B	86.35	73%	41%	64%	64.6	63	92%	A
B	86.7	79%	47%	68%	63	60	90%	A
C	75.8	47%	28%	46%	61.7	60	88%	B+
A+	97.3	121%	75%	73%	61	55	87%	B
C+	77.85	72%	40%	59%	56.4	55	81%	B
B	81.3	91%	53%	65%	54	51	77%	C
D	65.15	55%	31%	53%	48.8	47	70%	C
D	60.7	53%	30%	63%	44.8	43	64%	D
D	64.3	68%	37%	65%	43.9	43	63%	D
D	59.75	85%	49%	64%	34.4	32	49%	F

java prgs	final		final	java progs
			100	11
19	99
19	87
16	86
18	83
18	83
16	82
16	82
14	78
15	77
15	76
21	75
15	75
17	71
10	71		70	13
16	66
12	65		65	3
16	64		62	11
12	61
14	61
14	61
12	58
10	56		55	13
15	54		53	12
11	50
10	50
16	50
10	50
10	49		49	7
8	48
12	44
10	44
			41	10
			40	10
			37	13
14.0968	66.323	averages	57.2	10.3

I modified the previous final to the extent of removing three questions (35 pts) that concerned tracing two new applets and writing some code to solve a new problem. with 38 points relating to the Calculator applet and the lab with which everyone was supposedly familiar. I further warned on the homework scores that these two assignments had been poorly done by everyone. The performance on these “easier” questions was no better than the other class had done on their unfamiliar code questions (perhaps worse). Many people could not associate the logical role played by variables in the Calculator applet, even with the code in front of them. Most could not say what conditions triggered the change in these variables’ values with the code in front of them (probably because they have yet to learn to read Java code). Two students filled in the table correctly and three other filled it in half-way right. No one recognized that the calculation triggered by the equal button (get number in display and combine it with number1 using the last operation press (in myOperation) yielding myAnswer) needed to occur every time an operator button was pressed. The only difference between the = operator and the + operator was what happens to myAnswer and the other variables after the calculation. The equal button causes the value of myAnswer to be displayed, but the other operator button cause the value to be stored in number1 (where it will be used as an operand for the next operation).

The performance on the commenting of the lab program was even worse only three students (the top three scores) could answer over half of the 20 questions correctly. Only ONE student knew that a constant in Java was written in all caps (having been declared static and final) and hence that the constants used in the statement were PAYCASH (whose value had been declared to be 0) and myRegister.BYCASH (whose value had been declared to be 1 in MultipleRegister). Only two students knew that pType <2 tested for a CASH or CHECK transaction. No one recognized that calls to formatFloat() and readDouble() were made using the Class names because these are static methods and hence no instance name is available, in contrast to myRegister. Only one student knew that MultipleRegister objects like myRegister provided services such as deposit(), toString(), BYCASH, constructor, etc. and many suggested that such objects provided menus, float, int, enable(), etc. Unfortunately, the purpose of the review listing where java statements were presented so that you could remember where to look them up was totally wasted as many people were unable to remember that the abstract class was introduced with BasicCounter or that throws (for generating an exception object) was introduced with WarningCounter, or that writeUTF() was needed to send HeterogeneousMonitors to disk with a name introducing the data. Throws was introduced when we began doing io (SimpleInput) and the Enumeration interface was needed for UnorderedList. Somehow I let students complete the class with the idea that there was no need to understand examples and remember facts. Easy points were missed, such as writing the Movie class, which had been shown to have a four argument constructor, and a ratings and category method. Its internal attributes were described to be script, acting, and directing, and it inherited title and minutes from Attraction. Its category method returns “Movie”. Using its two methods, the displayAttraction() method of an Attraction object initialized to point to a Movie object would print “Movie rated at 14 lasts 88 minutes”. It was all plainly laid out on the page, but it was Greek to students who had not absorbed the point of the examples of the Counters hierarchy or the GenericStructures hierarchy, or the Menus hierarchy. Somehow most students got lost between the details of using the language (which had to be memorized) and the principles that the text illustrated over and over (which had to be observed). Neither memorization nor observation were in evidence on this final.