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 most students. Most submitted solutions worked, although fewer strudents than normal turned in work early (which was totally understanable given the size and time constraints of the assignment).

Taken together (over all three Programming Exams), about 57% of the students scored an A; another 21% scored a B.

The problem presented was a variant of the Reverse problem for graphs- with a simpler input format (more like that for SPE1 and SPE2). Most 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, extra puts for the map, etc.

My solution is in two forms: both the regular and generics form (with the later using the advanced form of the for loop to simplify the code).

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 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, most students got most classes to work here. A few had problems with the behaviors of the advanced simultons.

I have graded (and recorded the grades for) Quiz #4. The class average 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 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: Most students figured out the general idea here, but a few showed a large number of letters being printed. The most common mistake was printing BAA instead of BAAB for System.out.println(c); in the 2nd and 3rd part. Note that every method call uses the class of the object that c refers to: so the call to getID inside SuperClass calls the method specified in SubClass because it is being called on a SubClass object.

• Problem 2: 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; while log N grows slowly, this isn't really growing at all. Algorithms C was straightforward if you got my email about the orrect time for N=4,000.

• Problem 3: Many students got full credit here. Some seemed to guess on the 2nd and 3rd parts (which were missed most). The 2nd is just a straightforward loop that mimics the behavior of binary search, cutting the number in half each time. Note here, T(2N) is T(N)+1, the signature of (Log₂N). Likewise, the 3rd just does the standard loop from the 1st part, but does it 10 times: 10N is still O(N). For the forth part, a few students wrote O(N!), which is way to big; the exact answer is 1+2+3+...+(N-1) which is (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.

• Problem 4: Most students got most parts of this correct. Some students thought O(N) was a higher complexity class than O(N Log₂N). For the second part, we must assume the worst case (that the test is true). In the third part, many studens simplified this to O(N²) but you can't drop multiplicative terms if they are functions of N; you can only drop multiplicative terms if they are constant as well as additive terms if they are of a lower complexity class.

• Problem 5: Most students got a good start on this: some did not explain how they solved for c (-.5 points); others plugged and chugged incorrectly (many answers were way out of the ballpark, given a complexity class of O(NLog₂N). Remember, you should know that Log₂1000 is about 10 and Log₂N^a is aLog₂N, so Log₂1,000,000 = Log₂1000² = 2Log₂1000 = 20.

• Problem 6: Some students made some small mistakes here. I wanted you solve the equation 100 N = 10 N Log₂N algebraically: that is where the two time curves cross (at N = 1,024). I deducted .5 pts if you sampled these functions for different values of N. Finally, some students reversed the results, calling the linear algorithm faster for lengths less than 1,024 when that algorithm is faster for bigger values; it is exactly the opposite.

Scores on this exam ranged from 53 points to 103 points. At present the overall grades are 72% As, 21% Bs, and 7% Cs; I expect these numbers to be a good approximation to the final grade distribution.

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 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.

I did not have time to do a detailed analysis of the mistakes; if I have time this week I will post one here.

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 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. The few problems that arose mostly dealt with not throwing exceptions under exactly the right conditions.

Taken together (over the past two Programming Exams), about 64% of the students scored an A; another 14% scored a B.

There were many different mistakes made by students writing this class. Here were some of the most common problems (including poor Java use).

• In the declarations: not initializing used = 0;
• 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 an int, using an if/else which computes the wrong answer.
• 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 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 th eloop 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 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.

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.

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.

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 and one parameter from the method). Working solutions that did not use Catenate were not awarded many points.

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.

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

If you score better on Programming Exam #2 than on Programming Exam #1, I will count your Programming Exam #2 for both.

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 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:

• Not writing the whole class, starting with public class ...
• 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, 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 a String and int instance variables respectively.
• Not writing the header or body correct for seeIt: a void method that often (but not always) 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, most student did very well (achieving 8-10 points). Some students wrote solutions that would not work in general (they wouldn't work if the array values were not the same as the indexes; I should have put in more complicated arrays, but then it is harder to see if the result is correct). 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.

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 (a 1 point deduction). Likewise, some student are not putting their names/labs in the programs.

• In Part 1, almost everyone got the program working correctly. If there were problems, they mostly related to not using a correct constructor for BigInteger.

• In Part 2, most students got everything completely 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).

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.

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 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. 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.

• Problem 2: There were many 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 #4). About one point each was given to construction a StringTokenizer, write a loop, terminate the loop when there were no more tokens, get a token and check to see if it was .equals(word), printing the previous value and breaking, and updating the previous value.

• 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).

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; 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.
• In Part 4, some students computed an angle for the second test case (although no angle is possible, and the program should say so -see my executable).

Finally, 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.

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: About 1/2 the 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 a 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: About 1/2 the 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. Most students got full credit on this problem.

• Problem 6: Of those students who didn't get 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 1/2 the students got it completely correct, but others 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, a .5 point deduction, which will increase in later programs), most mistakes were in the Expression Test program and in the the Pizza Pricer.

• In Expression Test, while some students had incorrect expressions (each was about a .5 point deduction), many students had expressions with redundant parentheses (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.

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: 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 ++ as two tokens (it is one big operator token), tokenized the white space appearing between tokens (white space can occur in Strings 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 stored 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 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. 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 = (instead of ==) operators or wrote just x+y+z==10, not stating the condition for these values being in increasing order, or wrote x < y < z which uses incorrect syntax to express this condition (as we discssed in class).

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 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: 5 hours. Note that although there are 4 times, two of them were 1.5 hours.

• 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 ICS-H22 community, if you think you have spotted an error in an assignment, please contact me; and if it is an error, I'll tell you and announce it to the whole class. Don't make assumptions about what you are supposed to do.

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.

IMPORTANT: Students should also download and install the Barr-Courier Font on their computers. Again, explore the Online Resources link (see Miscellaneous, near the bottom of the page).

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.

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