• I've posted the Final Exam Study Guide. If necessary, I can try to clarify some of the questions, but I will not provide answers.
• The final exam is Thursday, May 5, 11:00-1:00, in DRLB A5 (our class has been in A7, not A5).
• CETS has made changes to the email system that seriously mess me up. If you must email me, allow plenty of time to get an answer; if you have multiple questions, please collect them together into as few separate emails as possible.
• I will post grades on Blackboard as soon as they are ready (so don't ask!). However, note that Blackboard will be down from 5:00 p.m. Wednesday, May 11, until mid-morning Saturday, May 14.

I've posted new versions of Piece.java and Board.java. The only way these are different is that several methods, when called with an unexpected null parameter, don't do anything (instead of giving a NullPointerException). If you are getting NullPointerExceptions from getX(), this should avoid that problem. If you are not getting exceptions from Piece.java or Board.java, you do not need to download these changed files.

If things are not being removed from the display when you "take" them, I am no closer to solving this problem, but you can use Tom's workaround: Whenever you take an object, take an additional step forward; this erases the taken object.

Pizza time! Third Wednesdays from 6-7:15 pm in Levine 307.

Final pizza: Wednesday, April 20

I've posted a new version of BoardGame.zip. The only changes in this version are that I've removed the erroneous toString() method from RoundPiece, and I've added a comment to Board.clear(). There is really no reason to download this new version; I just wanted to fix these things.

I've also posted a newer version of BoardGame.html, with brief added descriptions of Piece.redraw() and Board.clear().

I've updated the BoardGame.zip files to fix a serious error in removing a Piece from a Board. You should download these new files as soon as possible. My apologies for the inconvenience.

I've also added quite a bit more detail to my descriptions of how to handle Threads in Robot, part 3.

Pizza time! Third Wednesdays from 6-7:15 pm in Levine 307.

W Feb. 16
W Mar. 16 (right after spring break)
W Apr. 20 (almost end of classes)

If you recall, I don't count holidays and breaks when taking off late points. You shouldn't have to work those days. Hence, those days "don't exist" for grading purposes.

Recognizer programs turned in Friday, March 4 through Sunday, March 13, will therefore receive only a 5 point late penalty; and I'll extend that to Monday, March 14. Then it will be the usual: Tuesday, 10 points; Wednesday, 15 points; etc. So if you can't get the program done before break, you will have a little extra time after break.

I'll be available via email during Spring break, but I may not always respond immediately. I will not be in my office. (I too can use a break!)

Have a great (and safe) Spring break!

I do try to answer all the CIT594 questions that people email to me.

However, Penn has been rejecting email that I send from home, and I get no bounce messages to warn me that this has happened. (I have no problem receiving mail.) If you have sent me email and not gotten an answer, this is probably why. My apologies.

To be sure my mail is received, I have to use the slow-as-molasses Webmail, which I find extremely painful. Also, Wednesday through Saturday I will be at a conference, so I will be very slow in answering email (assuming I can do so at all).

Comments on the current assignment (Tree API):

• To the best of my knowledge, my JUnit tests are correct.
• The meanings of some operations were not unambiguously defined in class. I assumed that methods such as getChildren(), getSubtree(value), and deleteChild(subtree) referred to the immediate children of a node, and did not require a recursive search of all the descendants of a node. That is what my JUnit tests test for, so that is what your code should do.
  • Here's a simple rule of thumb that I just made up:
    • If you are not sure whether a method should do X or do Y, ask yourself:
      • If it does X, can I use the result X to (fairly easily) do Y? and
      • If it does Y, can I use the result Y to (fairly easily) do X?
    • then choose whichever one makes the other easier to do.
  • You might think about how this test applies to the above-named methods.
• It is preferable, but not required, to use generics in your code. I didn't use generics so that my JUnit tests could be run on Macintoshes. The "typesafe" warning messages you get are harmless. Feel free to add generics to my JUnit tests if you like (but don't change my tests to fit your code!).
• In general, when using a Tree node to represent a tree, the node represents itself and all its descendants, but none of its ancestors. Hence,
  • Equal trees are those whose values are equal and whose children are equal and in the same order. Parents are not relevant to this test.
• Since we didn't specify exactly what the result of toString(tree) should look like, you have to fill in the JUnit tests for that yourself.
• One of the easiest and best ways to implement the print() method is to print an indented list of node values.

  Example: For

  a / \ b c /\ /\ d e f g

  print:

  a b d e c f g

• There is no reason to prohibit nodes from having a null value.
• There is no reason to require that node values be Strings.
• There is no reason to limit the number of children a node may have.
• There is no reason to limit the depth of the tree.
• Think carefully about when you need nodes to be identical (==) and when you only need them to be equal.

I've reposted TreeTest.java with the corrections discussed in class.

You do not have to check for loops when you add a child. (If you have already done so, that's great; leave it in!)

Pizza time! Third Wednesdays from 6-8 pm in Levine 307.

W Feb. 16
W Mar. 16 (right after spring break)
W Apr. 20 (almost end of classes)

Last minute suggestions on the current assignment:

• If you are still debugging, and you haven't written equals and toString methods for all your classes, maybe you should do so. I didn't require them, but they are very helpful.
• Yes, you do need a constructor for ArithmeticExpression that takes an IntegerVariable.
• If you create constructors ArithmeticExpression(IntegerConstant c) and ArithmeticExpression(IntegerVariable v), then Java will complain about an ambiguous constructor when you say new ArithmeticExpression(null). (It doesn't know which one to use.) Probably the simplest solution is to combine these into a single constructor.
• You do need a HashMap in order to test IntegerVariable.
• If you can't perform the following sequence: Enter x = 2, get 2; then enter x + 3, get 5, then you are probably defining your HashMap in the wrong place. It should be defined in ExpressionTester (and in your JUnit tests).
• Yes, your ExpressionParser needs to know what HashMap to use, but that doesn't mean you need to make it an argument to the parse method. It could, for instance, be an argument to the constructor.
• If you implemented the algorithm correctly, you do not need parentheses around the entire expression.
• I'll say it again: Unary minus is not handled by my algorithm. -5 is not a number.
• If the expression evaluation throws an exception, your calculator should display a short error message (just the word "Error" is enough).
• The simplest way to distinguish between a number and a variable name is to look at the first character. See Character.isLetter(char ch) and Character.isDigit(char ch) in java.lang.

One (small) correction and two (small) clarifications:

• At the very beginning of your parse(String expression) method, append '$' to the expression.
• You need to create HashMaps in two places: in your JUnit test class, and in your ExpressionTester class.
• The evaluate method in Assign returns the value assigned

The posted assignment has been updated to reflect these changes.

Today's most popular error: Implicit super constructor BinaryTree<Operation>() is undefined. Must explicitly invoke another constructor. Why?

An uncommon but extremely mysterious error: Exception in thread "main" java.lang.VerifyError: (class: ArithmeticExpressionTest, method: testPrint signature: ()V) Unable to pop operand off an empty stack. This means you are using as a parameter to an assert method (probably assertEquals) a method that does not return a value--in this example, public void print().

I've posted my version of FloodFillApplet.java.

I've also posted, somewhat belatedly, the winner of last semester's programming competition, ShortestTokenCounter.zip, at 994 non-comment tokens. [I did some very minor editing on comments.] Remember, this competition was all about minimizing program size; no compromises were made for clarity or efficiency.

    public BinaryTree<T>(T value,
                         BinaryTree<T> leftChild,
                         BinaryTree<T> rightChild)

    public BinaryTree(T value,
                      BinaryTree<T> leftChild,
                      BinaryTree<T> rightChild)

First correction (you knew there would be some!):

The constructor ArithmeticExpression(Operation op) should be changed to ArithmeticExpression(IntegerConstant op). Constructing an arithmetic expression with any other operator and no children doesn't make any sense.

Error in EqualPiles.zip -- please download a fresh copy.

The assignment asks you to sort 5 numbers into 3 piles, but the earlier version of my problem generator insisted on having at least two numbers per pile. That is now fixed.

I've updated Eclipse FAQ to reflect the changes in Eclipse 3.1.

• Please check this FAQ before emailing me questions about Eclipse.
• Please let me know about any errors in or problems with this FAQ.

CS Survival Talk

Wed. Jan. 12, 4:30 pm in Heilmeyer Hall

Rosette Pyne, the SEAS representative in Career Services, will give an overview of Career Services, talk about writing resumes, and answer job hunting related questions.