Announcements

After I return your graded work in class on Monday, please download the Grades(zipped .xls file) from the course web and ensure that I have computed and entered your grade correctly (I'll be entering thousands of grades for students in my course this quarter, so even if I'm 99% accurate, I'm likely to record some incorrect grades. Note that all grades are recorded as integral values: I always round up (e.g., an programming score of 36.5 is recorded as 37).

If you do not pick up your returned work in class, you should pick it up during my office hours ASAP; I don't like keeping student programs: it makes my office messier, and you don't get the benefit of the feedback I wrote.

Generally, very good work by all students. Most submitted solutions worked; some didn't use referTo everywhere they could to simplify their code.

I have graded (and recorded the grades for) Quiz #8. The class average was about 18 (or about 73%) and the median was about 20 (or about 80%). Look at your returned work carefully; if your score was below 20 you might want to review this quiz with me or a TA. Material similar to this will be on the final written exam.

After I return your graded work in lecture on Tuesday, please download the Grades(zipped .xls file) from the course web and ensure that I have computed and entered your grade correctly (I'll be entering thousands of grades for students in my course this quarter, so even if I'm 99% accurate, I'm likely to record some incorrect grades. Note that all grades are recorded as integral values: I always round up (e.g., an exam score of 22.5 is recorded as 23).

If you do not pick up your returned work in class, you should pick it up during my office hours ASAP; I don't like keeping student exams: it makes my office messier, and you don't get the benefit of the feedback I wrote on the quiz.

There were some common "errors":

• Problem 1: Each problem scored 1 point for changing the right instance variable and 1 point for changing it to the right value. Most students seemed to handle the notation correctly (the tails of arrows belong in some variable box) but sometimes had some minor errors. Some students seemed unclear on what changes I wanted to have them make on the diagrams.

• Problem 2: Many students got full credit here. Some did not write a loop, others missed one of the continuation conditions (r != null && r.next != null which must be tested in that order)

• Problem 3: Some students got this fully correct. To get full credit you needed code to handle the base case correctly (test it -see Problem 2- and return 0), some conditional that tested r.value == r.next.value (or !=) and you needed to use the result of this test to return either the value computed by a recursive call on the rest of the list (or 1 more than that recursive call). The best recursive methods declare no new state and use no state change operators.

• Problem 4: Some students got this fully correct. To get full credit you needed code to handle the base case correctly (return null for null), and code to construct (new LN) a node in the result for every node in the original list). Many students changed values in the original list. You should not change the values in the original list; each value in the copy should either be the same as the value in the original list, or be substituted (see the parameters).

After I return your graded work in class on Monday, please download the Grades(zipped .xls file) from the course web and ensure that I have computed and entered your grade correctly (I'll be entering thousands of grades for students in my course this quarter, so even if I'm 99% accurate, I'm likely to record some incorrect grades. Note that all grades are recorded as integral values: I always round up (e.g., an programming score of 36.5 is recorded as 37).

If you do not pick up your returned work in class, you should pick it up during my office hours ASAP; I don't like keeping student programs: it makes my office messier, and you don't get the benefit of the feedback I wrote.

Generally, very good work by most students. Most submitted solutions worked, although fewer students than normal turned in work early (which was totally understanable given the size and time constraints of the assignment). Students seemed to have particular problems with SPE2 (which I guess was the result of the requirement to had that in early). On the non-generic SPE3 solutions, some students left in a few declarations that were generic (and therefore avoided doing explicit casting).

Taken together (over all three Programming Exams, including normalization points), about 33% of the students scored an A; another 17% scored a B, bringing the A/B average for this difficult instrument to 50%.

Some students got both parts (reading/printing and reversing the map) correct; some were able only to read/print the sorted map, others were able to read but not sort the map, and a few could not successfully even read the map.

Most Java points were deducted for writing extra code: for reading input in a more complicated way, and not using for-each loops when appropriate.

I have graded (and recorded the grades for) Quiz #7. The class average was about 20 (or about 78%) and the median was about 22 (or about 88%). Look at your returned work carefully; if your score was below 20 you might want to review this quiz with me or a TA. Material similar to this will be on the final written exam.

After I return your graded work in class on Tuesday, please download the Grades(zipped .xls file) from the course web and ensure that I have computed and entered your grade correctly (I'll be entering thousands of grades for students in my course this quarter, so even if I'm 99% accurate, I'm likely to record some incorrect grades. Note that all grades are recorded as integral values: I always round up (e.g., an exam score of 22.5 is recorded as 23).

If you do not pick up your returned work in class, you should pick it up during my office hours ASAP; I don't like keeping student exams: it makes my office messier, and you don't get the benefit of the feedback I wrote on the quiz.

There were some common "errors":

• Problem 1: Most students did well on this problem. Some didn't declare the answer/result using the standard form for collection classes: a type that is an interface; some didn't specify the generic information in <>. Some students indented the return statement as if it were inside the loop.

• Problem 2: Many students did well on this problem. Some didn't declare the answer/result using the standard form for collection classes: a type that is an interface; some didn't specify the generic information in <>. Some students used a second loop, which wasn't necessary and caused extra code. The important idea was to check whether or not each city (value from the first map) was a key in the second map: test m2.containsKey(m1.get(name)); for every name that is a key in the first map.

• Problem 3: There were many different grades for this problem. The legal/illegal part was governed by the type of the variable declared; the value(s) printed were governed by the class of the object constructed. I'm going to assume that some students typed in the code to get the answers here; that won't help you on the final exam. You need to understand the answers and be able to do something similar in the future.

I have graded (and recorded the grades for) Quiz #6. The class average was about 20 (or about 78%) and the median was about 21 (or about 87%). The last time I taught this class the average was about 87%. Look at your returned work carefully; if your score was below 20 you might want to review this quiz with me or a TA. Material similar to this will be on the final written exam.

After I return your graded work in class on Wednesday, please download the Grades(zipped .xls file) from the course web and ensure that I have computed and entered your grade correctly (I'll be entering thousands of grades for students in my course this quarter, so even if I'm 99% accurate, I'm likely to record some incorrect grades. Note that all grades are recorded as integral values: I always round up (e.g., an exam score of 22.5 is recorded as 23).

If you do not pick up your returned work in class, you should pick it up during my office hours ASAP; I don't like keeping student exams: it makes my office messier, and you don't get the benefit of the feedback I wrote on the quiz.

There were some common "errors":

• Problem 1: Some students got full credit here. Some seemed to guess on the 2nd and 3rd parts (which were missed most). The 2nd executes the statement 10N times, so even though it is inside two loops, the complexity class is O(10N) = O(N). For the 3rd part, few students wrote out the exact answer, 1+2+3+...+(N-1), which can ber simplified to (N-1)N/2, which is O(N²). I took off 1/2 point for not showing your work, not using big-O notation, or for writing something like O(10N); write just O(N) since all constants are removed. Many students lost 1/2 point for not showing the sum in the last part and just saying the nested loops were each O(N).

• Problem 2: Most students got most parts of this correct. For the second part, we must assume the worst case (that the test is true): that test is O(1) and must be included in the complexity class computation. In the third part, many students added instead of multiplied.

• Problem 3: Most students got a good start on this: some did not explain how they solved for c; others computed this constant incorrectly (many answers were way out of the ballpark, given a complexity class of O(N²), which is quadratic (so increasing the size by a factor of 1,000 should increase the running time by a factor of 1,000,000).

• Problem 4: Most students got full credit here. Notice for Algorithm A, each doubling goes up by about a factor of 4 (and going from 1,000 to 4,000 goes up by a factor of 16). For Algorithm B, the time stayed the same about the same for each doubling. Algorithms C was straightforward, doubling as N doubled.

• Problem 5: Some students made some small mistakes here. I wanted you solve the equation 100 N = 10 N² algebraically: that is where the two time curves cross (at N = 10). Finally, some students reversed the results, calling the linear algorithm faster for lengths less than 10 when the correct answwer is that algorithm is faster for bigger values; it is exactly the opposite. You don't need to "try" values less 10 and greater than 10; the linear algorithm will eventually be faster (for big N).

• Problem 6: Most students did well here, separating the cases (key in/not-in the map) and doing the appropriate operation in each case.

After grading the three most recent instruments (Exam #1, In-Lab Programming Exam #2, and Program #5), the overall grades are 33% As, 27% Bs, 30% Cs, and 10% below Cs. The average over the entire class is 82%.

After I return your graded work in class on Tuesday, please download the Grades(zipped .xls file) from the course web and ensure that I have computed and entered your grade correctly (I'll be entering thousands of grades for students in my course this quarter, so even if I'm 99% accurate, I'm likely to record some incorrect grades. Note that all grades are recorded as integral values: I always round up (e.g., an programming score of 36.5 is recorded as 37).

If you do not pick up your returned work in class, you should pick it up during my office hours ASAP; I don't like keeping student programs: it makes my office messier, and you don't get the benefit of the feedback I wrote.

Generally, very good work by most students (although a few students turned in code with many methods not working correctly). For many students, the problems that arose mostly dealt with not throwing exceptions under exactly the right conditions.

Taken together (over the past two In-Lab Programming Exams), about 20% of the students scored an A; another 20% scored a B.

Because In-Lab Exam #1 and #2 had large components dealing with writing code and classes, if any student scored higher on in-Lab Exam #2, that score will count for both In-Lab Exams.

There were many different mistakes made by students writing this class. Here were some of the most common problems (including poor Java use). I would strongly recommend that you review the code in my solution to gain a better understanding of the programming involved.

• In the declarations: not initializing used = 0; explicitly.
• In the constructor: not checking for or throwing the exception, not allocating an array of Object to store the set (see the doubleLength method for an example of how this is done). Some student did not write the correct prototype, either specifying private, a void return type, or not having an int parameter.
• In the lookupIndex method: using the wrong upper bound in the for loop (should be < used: some students used <= and some used set.length), using == instead of .equals, returning an Object instead of its int index int, using an if/else which can compute the wrong answer immediate (on the first loop iteration).
• In the add method: doubles before checking whether the value needs to be stored in the array, not storing the values in the next index in the array (used), not incrementing used, not returning the correct boolean value, not calling lookupIndex or contains to check whether the value was already stored in the set.
• In the getSize method: not just returning used (some students looped to count the number of non-null values in the array, but this is already stored in used).
• In the makeEmpty method: not setting used = 0; and/or not resetting all the used values in the array to null (note that ' only values 0 to used-1 need to be reset). There is no need to reallocate the Object array.
• In the contains method: using the wrong upper bound in the for loop (should be < used: some students used <= and some used set.length), using == instead of .equals, returning an Object instead of an int, using an if/else in the loop which computes the wrong answer. Not calling lookupIndex to check whether the value was already stored in the set, or calling this method but not directly returning whether it was != -1 and instead using an if/else.
• In the removeRandom method: not checking/throwing the exception, not storing (and then returning) the correct value, using the wrong upper bound in the shifting for loop (should be < used-1: many students used < used;), not shifting from a higher to a lower index, not decrementing used after removing one value, not storing null at the end of the used array.
• Generally, don't write an if statement that returns a boolean literal: instead return just the if's test (or return its negated value)

Scores on this exam ranged from 14 points to 96 points.

After I return your graded work in class on Tuesday, please download the Grades(zipped .xls file) from the course web and ensure that I have computed and entered your grade correctly (I'll be entering thousands of grades for students in my course this quarter, so even if I'm 99% accurate, I'm likely to record some incorrect grades. Note that all grades are recorded as integral values: I always round up (e.g., an exam score of 82.5 is recorded as 83).

If you do not pick up your returned work in class, you should pick it up during my office hours ASAP; I don't like keeping student exams: it makes my office messier, and you don't get the benefit of the feedback I wrote on the exam

I would strongly recommend that you review the code in my solution to gain a better understanding of the programming involved.

Here is a quick summary of information for each of the problems.

1. Expressions Average was 79% (with 7 students scoring perfectly).
2. Exceptions Average was 68% (with 8 students scoring perfectly).
3. Boxing and Compact Trace Table Average was 70% (with 2 students scoring perfectly).
4. Using Classes Average was 50% (with 1 student scoring perfectly).
5. String Tokenizer Method Average was 60% (with 3 students scoring perfectly).
6. removeAt Method Average was 51% (with 1 student scoring perfectly; many students forgot to decrement used ).
7. Arrays/Interfaces Average was 73% (with 9 students scoring perfectly).
8. Volatile Class Average was 34% (with 1 student scoring perfectly).
9. Short Answers Average was 54% (with no students scoring perfectly).

After I return your graded work in class on Wednesday, please download the Grades(zipped .xls file) from the course web and ensure that I have computed and entered your grade correctly (I'll be entering thousands of grades for students in my course this quarter, so even if I'm 99% accurate, I'm likely to record some incorrect grades. Note that all grades are recorded as integral values: I always round up (e.g., an exam score of 22.5 is recorded as 23).

If you do not pick up your returned work in class, you should pick it up during my office hours ASAP; I don't like keeping student exams: it makes my office messier, and you don't get the benefit of the feedback I wrote on the quiz.

I would strongly recommend that you review the code in my solution to gain a better understanding of the programming involved.

For problem 1, the mistakes mostly related to the type of parameter for the constructor (and type of instance variable it was stored into). LengthLess is too specific (and you cannot generalize the class for problem 2)and Object is too general (although you can generalize by casting to include problem 2): Decision is just right. It ensures as compile-time that the object passed to the constructor will have an isOK method and requires no casting (and therefore likely to not throw run-time exceptions).

For problem 2, students also did well. The only reoccuring problem was calling .toString instead of casting the parameter to a String. While calling .toString worked here, generally classes that implement Decision require casting, and it is a "more correct" (and faster) solution. Note that your isOK method must have an Object parameter, otherwise Java will mark you class as not correctly implementing the Decision interface.

For problem 3, there was more variation. The whole point of this problem was to construct and use and object from the Catenate class (passing its constructor an object constructed from the Prefix class which was constructed with one parameter from the method). Then, the other code reads every string from the file and passes each to the .tryIt method from the constructed Catenate class, which does all the work. Working solutions that did not use Catenate were not awarded many points; they duplicated the code inside Catenate.

After I return your graded work in class on Monday, please download the Grades(zipped .xls file) from the course web and ensure that I have computed and entered your grade correctly (I'll be entering thousands of grades for students in my course this quarter, so even if I'm 99% accurate, I'm likely to record some incorrect grades. Note that all grades are recorded as integral values: I always round up (e.g., an programming score of 36.5 is recorded as 37).

If you do not pick up your returned work in class, you should pick it up during my office hours ASAP; I don't like keeping student programs: it makes my office messier, and you don't get the benefit of the feedback I wrote.

Generally, very good work by most students. There were a few static methods that performed poorly on boundary cases; a few compareTo/equals methods in BigRational that did not compute correct results (compareTo should return an int and neither should use ==); a few update methods in Ball that did not perform the simulation correctly (mostly having to do with forgetting to multiple the average velocity by dT): they created jerky simulations, not at all like my executable.

Many students had difficulty with the first problem, which in my mind was very similar to the prep problem: the one new idea is that you had to call nextToken once before the loop; after that it is identical to the prep problem (except using compareTo instead of .length). Most students did well on the second problem (as I expected) because all simple classes look alike.

A good metric for your midterm performance is the average of the midterm writen exam and your first two in-class programming exams.

As an incentive, and acknowledging that in-class programming exams are a new form of testing for you, if you score better on Programming Exam #2 than on Programming Exam #1, I will count your Programming Exam #2 for both.

Look at your returned work carefully; if your score was below 20 you might want to review this quiz with me or a TA. Material similar to this will be on the midterm written exam.

After I return your graded work in class on Tuesday, please download the Grades(zipped .xls file) from the course web and ensure that I have computed and entered your grade correctly (I'll be entering thousands of grades for students in my course this quarter, so even if I'm 99% accurate, I'm likely to record some incorrect grades. Note that all grades are recorded as integral values: I always round up (e.g., an exam score of 22.5 is recorded as 23).

If you do not pick up your returned work in class, you should pick it up during my office hours ASAP; I don't like keeping student exams: it makes my office messier, and you don't get the benefit of the feedback I wrote on the quiz.

Generally students made lots of small mistakes that one makes when writing classes for the first time. I hope between seeing my comments on your quizzes and reading my solutions that you get a solid understanding of all the parts of a simple class. Here were some common mistakes for Questions #1:

• Using static fields and methods. Yes, you can get this to work in Eclipse if you always construct just one object; but if you construct more than one, then the different objects would not have their own state (they would share the static state, and therefore not work correctly.
• Not checking for illegal arguments/parameters in the constructor and throwing an exception (with some useful String)
• Not copying the parameters to the instance variables in the constructor (once they are found to be OK). Some students are confused about using parameters and instance variables in constructors.
• Not writing the header or body correct for getCatenation and getCount; both are parameterless, returning some String and int instance variables respectively.
• Not writing the header or body correct for seeIt: a void method that changes the state of some instance variables (some students didn't change the state correctly).
• Not declaring instance variables.
• Not declaring instance variables to be private.
• Not specifying correct initializations for the instance variables. Those variables receiving values in the constructor should use default intialization; the other variables should be initialized explicitly.

For problems 2-6, many student did very well (achieving 8-10 points). I took off points for code that was overly complex: if you are writing complicated code for these simple operations, you will have a very hard time debugging code for more complicated array manipulations. Some students also created second arrays, when everything could be done fairly easily with the one array supplied (and in the reverse method, I explicit said to create no new arrays).

After I return your graded work in class on Monday, please download the Grades(zipped .xls file) from the course web and ensure that I have computed and entered your grade correctly (I'll be entering thousands of grades for students in my course this quarter, so even if I'm 99% accurate, I'm likely to record some incorrect grades. Note that all grades are recorded as integral values: I always round up (e.g., an programming score of 36.5 is recorded as 37).

If you do not pick up your returned work in class, you should pick it up during my office hours ASAP; I don't like keeping student programs: it makes my office messier, and you don't get the benefit of the feedback I wrote.

There are stll a few students who have .java files that mismatch the name of their classes. Likewise, some student are not putting their names/labs in the programs.

• In Part 1, almost everyone got the program working correctly, although a very few pairs always computed a cycleCount of 1 or looped infinitely (with a wrong test); one pair didn't make cycleCount a BigInteger too. A few pairs were still prompting with PromptInt so they couldn't enter a large value to test. If there were other problems, they mostly related to not using a correct constructor for BigInteger.

• In Part 2, most students got most parts correct. I did take points off for each of the following: (a) not constructing a DiceEnsemble for each player, (b) not calling getRollCount to help compute some statistic (using an extra counter for that job), and (c) declaring no variables in local blocks inside the main method: you should work on declaring variables in the most restricted scope that you can.

• In Part 3, some students did not finish this problem (and some did not use the StringTokenizer class, which is required by the problem statement). Some students did not use case-insenstive comparisons: e.g., equalsIgnoreCase. Many students did not call nextToken in pairs; the result was that if you looked up a "telephone" number, the program would print the name of the next person in the String (not the previous person, who actually had that phone number); this caused an exception if the last phone number was entered.

Finally, a few students forgot to use the form of Prompt.forBoolean that specified a default value. Please check the Javadoc for this version if you did not use it correctly.

Look at your returned work carefully; if your score was below 20 you might want to review this quiz with me or a TA. Material similar to this will be on the first written exam.

Because the average was below 75%, students will receive about 1.2 normalization points to bring the class average to 75% (these points are not given to students individually -your score is still your score- but are added to the totals of every student when computing their final grade); it is effectively as if you scored about 1.2 more points on this quiz (about 5 percentage points).

After I return your graded work in lab on Wednesday, please download the Grades(zipped .xls file) from the course web and ensure that I have computed and entered your grade correctly (I'll be entering thousands of grades for students in my course this quarter, so even if I'm 99% accurate, I'm likely to record some incorrect grades. Note that all grades are recorded as integral values: I always round up (e.g., an exam score of 22.5 is recorded as 23).

If you do not pick up your returned work in class, you should pick it up during my office hours ASAP; I don't like keeping student exams: it makes my office messier, and you don't get the benefit of the feedback I wrote on the quiz.

Here were some common mistakes:

• Problem 1: Most students got full or close to full credit here. Some pictures did not show correct references; others showed two declared variables with the same name; a few had arrows whose tails were not in the center of the box, or arrows that had no heads; a few changed many arrows, instead of just ONE, when a new reference was stored in s1. Remember, arrows point at ovals, NOT at other variable boxes (e.g., what s2 = s1 does). Note that the compareTo method returns an int not a boolean; you could have said that the value is >0 and gotten full credit: all programmers do with the result of compareTo methods is compare them to zero.

• Problem 2: There were some totally correct or close to correct solutions, but the ones that were not were often very wrong. The semantics of the methods in the StringTokenizer class take some getting used to (which I hope you will, in this quiz and in Programming Assignment #3). Points were earned for constructng a StringTokenizer, writing a loop, terminating the loop when there were no more tokens, getting a token and check to see if it was .equals(word), printing the previous value and breaking, and updating the previous value (with current).

• Problem 3a: Overall, poor performance although some students did well. There are simple rules that you can use to answer these questions, but most students seemed very confused and did not know which rules to apply. If you have questions, please ask them in class, send email to me or the mailing list, etc.

• Problem 3b: Much like 3a. These questions were harder because they asked you to synthesize, not just analyze code (but really you were analyzing access modifiers). You need to understand the rules for understanding access modifiers to effectively use classes that are in libraries (like mine and Java's).

We will go over this quiz in lecture on Tuesday.

After I return your graded work in class on Monday, please download the Grades(zipped .xls file) from the course web and ensure that I have computed and entered your grade correctly (I'll be entering thousands of grades for students in my course this quarter, so even if I'm 99% accurate, I'm likely to record some incorrect grades. Note that all grades are recorded as integral values: I always round up (e.g., an programming score of 36.5 is recorded as 37).

If you do not pick up your returned work in class, you should pick it up during my office hours ASAP; I don't like keeping student programs: it makes my office messier, and you don't get the benefit of the feedback I wrote.

Besides a few students submitting programs that weren't immediately runnable (because the class name did not match the file name or because they put their code in a package, or incorrectly commented-out some line, each a .5 point deduction). The common mistakes were

• In Part 1, some students generated random numbers in an incorrect range; others forgot to multiply the ratio by 4; still others used int counters (as they were supposed to) but did not cast these values to double so Java performed integer division so their approximations were not good; some students did not follow directions and left in statements that printed intermediate information.

• In Part 2, some students wrote code incorrectly for the case where the sentinel was the first value (or didn't comment-out the print statements, but instead removed them). Some students computed statistics wrong or neglected to compute them.

• In Part 3, some students did not trace outputs in the form of my executable. Others computed a 50%/50% win ratio (or 33%/66%), instead of the 66%/33% switch vs. stay ratio.

Some students declared "counter" variables to be double instead of int and some required two Prompt.forInt calls in their loops (for getting a positive value) when one sufficed with the "right" kind of loop.

Finally, some students had a big if for tracing, duplicating much code in both the true and else parts. Look at my code, which had many smaller if statements each determining whether to trace a part of the computation.

Note the back page: we did not deduct points for style, but we indicated where you did not perform as well as you should have. We will grade on style for Programming Assignment #3.

After I return your graded work in class on Wednesday, please download the Grades(zipped .xls file) from the course web and ensure that I have computed and entered your grade correctly (I'll be entering thousands of grades for students in my course this quarter, so even if I'm 99% accurate, I'm likely to record some incorrect grades. Note that all grades are recorded as integral values: I always round up (e.g., an exam score of 22.5 is recorded as 23).

If you do not pick up your returned work in class, you should pick it up during my office hours ASAP; I don't like keeping student exams: it makes my office messier, and you don't get the benefit of the feedback I wrote on the quiz.

Here were some common mistakes:

• Problem 1: Most students did well on this problem. The most "missed" statement was the declaration statement. Other students listed two or three different kinds of if statements separately. Some students didn't put * after any statements; some put them after all the statements; still other students did not put a * after blocks (which are the simplest form of control structure) or breaks (which technically are a control structure -they affect what statement is executed next, but different than the other control structures because we don't see statement mentioned in their EBNF).

• Problem 2: Few students got full credit on this problem. Part 1 had no state-change operator evaluated last (or at all). Part 2 incremented y to 4, and then stored that value into x as well. Part 3 had an illegal operand for the state change operator ++. Part 4 incremented x, but then the = operator took x's oldvalue (it is a postfix ++) and stored it back into x; so, the expression statement x++; or ++x; increments x; for that matter even x = ++x; works (although it is overly complex), but NOT x = x++;. In Part 5, many students got full credit, although this expression statement is complicated, it is syntactically correct.

• Problem 3: Most students missed at least one part of this problem. Most got part (a) correct. Many got tricked by part (b): any method call is a legal expression statement, even if it returns a value that is not stored or printed somewhere (unlike operators, where the last operator must be a state-change operator). This is certainly strange, but this is what Java allows. Part (c) is the standard story about void methods; to get full credit on this part you should have used the word void.

• Problem 4: Many students got 4-5 points for writing this code. There were VERY VERY many different ways to write this code correctly. Common problems were failure to print the extreme values (1 and 100); failure to put spaces between values; failure to increment (in any form) the counting variable; failure to go to the next line after printing multiples of 10s (some students don't know the semantics of the System.out.println method); printing some values twice.

• Problem 5: Generally syntax errors are considered better to have, as the Java compiler points them out to us for fixing; for execution errors, we get no such help. Many students got 1/2 credit on this problem, for saying syntax errors are better but not describing why very well.

• Problem 6: On part a, very few students got full credit: there were lots of different errors so compare your solution to mine if you did not get this one perfect. On part b, more students got full credit, but still not a lot: some did not write compact trace tables; others forgot to show the prompt or the input that followed it -in the Console column; others just performed the hand simulation incorrectly.

• Problem 7: About 20% of the students got it completely correct, but many had no idea what to do: a loop with a try/catch that printed lots of interesting things. If you didn't get this correct, figure out exactly why, to the point that you could solve other similar problems that might appear on later testing instruments (hint hint).

After I return your graded work in class on Tuesday, please download the Grades(zipped .xls file) from the course web and ensure that I have computed and entered your grade correctly (I'll be entering thousands of grades for students in my course this quarter, so even if I'm 99% accurate, I'm likely to record some incorrect grades. Note that all grades are recorded as integral values: I always round up (e.g., an programming score of 36.5 is recorded as 37).

If you do not pick up your returned work in class, you should pick it up during my office hours ASAP; I don't like keeping student programs: it makes my office messier, and you don't get the benefit of the feedback I wrote.

Besides a few students submitting programs that weren't immediately runnable (because the class name did not match the file name or the class was put in a package: a 1 point deduction, which will increase in later programs).

• In Expression Test, while some students had incorrect expressions (each was about a 1 point deduction), many students had expressions with redundant parentheses (each was about a .5 point deduction; see my solutions).

• In Pizza Pricer
  1. Some students did not declare the right types for the different variables (int vs. double), or did not prompt using the correct method (relying on Java to implicitly convert the value).

  2. A few students computed the cost/person incorrectly.

  3. A few students computed $/in^2 instead of cents/in^2.

  4. Many students declared the diameter as an int, as they should have, but then wrote diameter/2 which truncates the result for an odd size diameter. See the bottom of the required grade sheet for ways to have avoided this problem: my favorite is explicit casting and double literals.

After I return your graded work in class on Friday, please download the Grades(zipped .xls file) from the course web and ensure that I have computed and entered your grade correctly (I'll be entering thousands of grades for students in my course this quarter, so even if I'm 99% accurate, I'm likely to record some incorrect grades. Note that all grades are recorded as integral values: I always round up (e.g., an programming score of 18.5 is recorded as 19).

If you do not pick up your returned work in class, you should pick it up during my office hours ASAP; I don't like keeping student programs: it makes my office messier, and you don't get the benefit of the feedback I wrote.

Here were some common mistakes:

• Some students did not remove all the italicized comments from the questionnaire.

• Some students, in answer to the question "...how many scheduled office hours do I have each week" cut and paste my office hours, but did not supply the answer: 4.5 hours.

• Some students confused the TA with the Lab Tutor.

• Some students confused the midterm (written) exam with the first in-class programming exam.

• Some students listed the URL for two comics on my web page but did not name them.

• Some students did not have a class name compatible with their file name, and so a project created from the file did not run immediately. Ensure any file name you submit, when put in a project file and loaded into Eclipse, compiles and runs.

• Some students corrected the spelling of "scceeded" to "succeeded". Please, if you think you see any mistakes in the assignment, ask me what to do. A few students did in this case, and I told them to keep the incorrect spelling. As a classmember and part of the INF-42 community, if you think you have spotted an error in an assignment, please contact me (or better yet post on the class email list); and if it is an error, I'll tell you and the rest of the class. Don't make assumptions about what you are supposed to do.

After I return your graded work in class on Tuesday, please download the Grades(zipped .xls file) from the course web and ensure that I have computed and entered your grade correctly (I'll be entering thousands of grades for students in my course this quarter, so even if I'm 99% accurate, I'm likely to record some incorrect grades. Note that all grades are recorded as integral values: I always round up (e.g., an exam score of 22.5 is recorded as 23).

If you do not pick up your returned work in class, you should pick it up during my office hours ASAP; I don't like keeping student exams: it makes my office messier, and you don't get the benefit of the feedback I wrote on the quiz.

Here were some common mistakes:

• Problem 1: Lots of small mistakes here; most are in the "Common Errors" section in the Tokens lecture. Quite a few students specified forInt as two keywords or as a keyword followed by an identifier (it is one identifier). A few others didn't tokenize int, x, or = (the first three tokens), tokenized <= or ++ as two tokens (they are one big operator token), tokenized the white space appearing between tokens (white space can occur in String and comment tokens), tokenized }; as one separator token (it is two), and finally, tokenized things "inside" comments (they are all part of one big comment token). Some students did not write the types of the literals.

• Problem 2: Part 1's syntax was legal, but initializes only one variable; in real code, the other might be set later in an expression statement. Part 2 was illegal because it tried to use a double to initialize an int variable (there is no implicit conversion this way). Part 3, both declarations are legal; the second stores 3 into y (from the first declaration) and then it was implicitly converted into 3. and stored into the newly declared double variable x.

• Problem 3: Some students didn't know the form in which to write prototypes; some did not correctly determine the return type or the type of (one or more of its) operands; many wrote too few operands; a few students tried writing code to perform the calculations, which is unnecessary in a prototype.

• Problem 4: Lots of small problems here (especially related to implicit conversion and casting, and writing values of the right type). Probably the most missed parts were e, g, i, and j (including writing 611 vs. the right answer "611". Ensure you know the difference between e and f. See my solutions; if you still don't understand them, see me.

• Problem 5: Many students didn't fully circle or label literals; some didn't fully circle or label variables. Many students didn't correctly circle the negate unary operator and its literal subexpression 1. Some students applied the + operator before the * operator (ignoring operator precedence). Some students didn't circle the y - 2 expression. In a few cases, types/values were missing or mislabelled.

• Problem 6: A huge number of students wrote 5/9*... which results in 0 (then converted to the double 0.; same for 3/2: write it as 3./2. or just 1.5). Many students forget to parenthesize denominators: .../(2*(A+B)) Many students used redundant parentheses: when removed, the expression's operators were still evaluated in the same order. Many students either left part e blank or used the = (instead of ==) operator or wrote just x+y+z==10, not checking for the condition for these values are in increasing order, or wrote x < y < z which uses incorrect syntax to express this condition (simlar to an example we discssed in class).

Specifically, read the handout on Java and Eclipse (Download/Installation Instructions) for details. Please contact me if you are having trouble, as I will assume every has successfully downloaded and installed this software by the end of the first week of classes.

I will never remove a message from this page, although a subsequent message may "cancel" a previous one; in such a case, I'll refer to the number of a canceled message in the message that cancels it.

Expect a few new messages to be posted here each week.

Check this page, along with the the course email discussions, daily.