CIT 594 Old Announcements
Spring 2008, David Matuszek

Date Announcements
Thu May 8 Recommended talk today Thursday May 8, 4:00-5:00 in Drexel's Patten Auditorium (Matheson Hall room 109):

Dr. John Hopcroft: "Computer Science in the Information Age"The last forty years have seen computer science evolve as a major academic discipline. Today the field is undergoing a major change. Some of the drivers of this change are the internet, the world wide web, large sensor networks, large quantities of information in digital form and the wide spread use of computers for accessing information. This change is requiring universities to revise the content of computer science programs. This talk will cover the changes in the theoretical foundations needed to support information access in the coming years.

Professor Hopcroft is the 1986 Turing Award Winner and one of the most influential computer scientists in the world. The Turing Award in computer science is equivalent to the Nobel prize in physics or chemistry.

F May 2The final exam will contain questions from all my lectures, though there will be more emphasis on material covered since the midterm. It will also contain questions from (only) the last four chapters of The Pragmatic Programmer.
F May 2If you are at all interested in the underlying electronics, the recent discovery of the memristor is the most exciting development I've seen in years.
April 24, 2008Here's a bit of code used for Drawing a Bug.
April 24, 2008 Here are some Example Bugs Programs.
April 23, 2008I have added brief descriptions of how to interpret the various node types that you didn't interpret for part 1. It was convenient to add them directly to the Interpreter Part 1 assignment. They are boldface, so the additions are easy to find.

I have also written up some notes on Writing the Bugs Interpreter.
April 21, 2008
  • I will not be in at all today (Monday).
  • I am cancelling the extra session this evening; I'll talk more about the assignment in class.
  • I'm extending the due date for Bugs Interpreter, Part II to midnight Sunday, April 27.
  • I will give you one more (small!) assignment this Thursday.
April 20, 2008 Mai has started a new web site, MCIT Hub. Check it out!
April 20, 2008 Due to the difficulty of the current assignment (Bugs Interpreter, Part II), I will have a (totally optional) question-and-answer session Monday, April 21 at 6:30 in Moore 307.
April 17, 2008 There is a "town meeting" today, 3-4:30, in Levine 307, "to give masters students the opportunity to voice concerns, suggestions, etc., re: the masters programs....All CIS/MSE, CGGT, & MCIT students are invited to attend." There will be pizza.
April 15, 2008

Yet another oversight frowny face: I forgot to specify that your Bug constructor should have one parameter, the name of the bug (as a String). It's too late to require this, but it will ease our testing if you can provide such a constructor.

The ParserTest.java I provided uses DavesTreeParseMethod.parse in the makeTree method. You can replace this with your Tree.parse. I did this for grading your programs, so that if your parse method is broken it won't cause all my tests to fail.

Also, it uses a Token constructor with only one argument. Here's the code you need:

/**
* Constructor for Tokens.
* @param value The characters making up the token.
*/
public Token(String value) { this.type = determineTokenType(value); this.value = value; } private Type determineTokenType(String value) { char firstCharacter = value.charAt(0); if (firstCharacter == '\n') return Type.EOL; else if (Character.isLetter(firstCharacter)) { if (value.equals("EOF")) return Type.EOF; else if (isKeyword(value)) return Type.KEYWORD; else return Type.NAME; } else if (Character.isDigit(firstCharacter)) return Type.NUMBER; else if (firstCharacter == '.') { if (value.length() == 1) return Type.SYMBOL; else return Type.NUMBER; } else return Type.SYMBOL; }

If you don't have an isKeyword method, it's not hard to write one.

April 15, 2008

Apparently, I also forgot to include numbers and variable names in the list of things that you need to evaluate. So:

  • To evaluate a number, use Double.parseDouble(numeral).
  • To evaluate a variable name, fetch it from your HashMap.
April 15, 2008

New postings:

Also, a couple of people have pointed out that I forgot to include block in the list of node types that need to be interpreted. I hope everyone realized that you can't do the rest of the assignment without interpreting blocks!

April 13, 2008 I've posted some Interpreter Notes.
April 12, 2008 Robert Beck has figured out how to import one package into another in NetBeans; I've added the directions to Turning in the Parser assignment. (Although the Parser assignment is done, the technique will be needed again.) Thanks, Robert! 
April 8, 2008 Turning in the Parser assignment.
April 7, 2008 If you lost points on the parse(String) method in the Tree class, here's how you can make them up.
April 7, 2008 Error in assignment:
An Allbugs node has exactly two children: A list node with zero or more var children, and a list node with one zero or more function children.
(In Allbugs and in Bug, functions are allowed but not required. )
April 7, 2008

I've gotten a number of questions about whether certain children should be omitted from the AST. The rule is this: If a node has children of different kinds (for example, a function node has a name, a var parameter list, and a block body), then all children must be present. This is so that we know exactly where to find each kind of child (in this example, the body is always the third child).

If a node has a variable number of children, all of the same kind (list, var, block, and switch), then it may have zero children. Hence, a function with no parameters still has a var child, but that var child does not have children.

April 5, 2008 I've added a page with a Parser clarification ("Only keywords are KEYWORDs") and a test program with a complete example Bugs program.
April 1, 2008
pizza

Pizza! Hoagies! Pizza! Hoagies!

Thursday April 3, 6:00 - 7:30
Levine 307

Who is invited: All current and former MCIT students and faculty, and students taking MCIT classes. OK to bring a guest.

March 31, 2008 I have made some Corrections to the Parser Assignment.
March 25, 2008 I won't be holding office hours Wednesday-Thursday-Friday of this week. (I'll be attending a conference at Drexel.)
March 24, 2008 If you are still having trouble with the parse(String) method, I've expanded the comments below into a page of suggestions. It even includes some code and pseudocode.
March 20, 2008

Addition to Tree API assignment: Also provide an @Override public boolean equals(Object obj) method. (It's really hard to do JUnit testing without this!)

Minor corrections:

  • public Tree getChild(int index)   should be
    public Tree<V> getChild(int index)

  • public Iterator iterator()   should be
    public Iterator<Tree<V>> iterator()

  • public static Tree parse(String treeDescription)    should be
    public static Tree<String> parse(String treeDescription)

If you have started this assignment, you will have discovered that the parse(String) method is really difficult. It helps if you use the techniques you learned from the Bugs Recognizer assignment. I also recommend using a StringTokenizer and adding either a void pushBack(String token) method or a String peek() method to it. Don't be afraid to write several helper methods along the way.

March 20, 2008 Barack Obama answers a computer science question (1 minute 24 seconds)
March 17, 2008 I have added a Threads section to the list of CIT594 exam questions.
February 26, 2008 Correction for reading real numbers: Errata #5.
February 25, 2008 Two more changes--fortunately, both very minor. See Errata #4.
February 21, 2008

Combined errata for the Recognizer assignment:

  • Errata #1: isFactor(), color names, <do statement>, isParameterList(), <moveto action>.
  • Errata #2: <turn action> and <turnto action>, <switch statement>, <initialization block>, and <bug definition>.
  • Errata #3: createTokenizer() and isFollowedBy(Recognizer, String).
  • Errata #4: <var declaration> needs <eol>, and isFactor() should handle unary operators.
  • Errata #5: Remove the cast to int from Recognizer.nextToken().
February 12, 2008 Added a brief comment to my page of observations saying, basically, that the Controller and View don't have to be in separate classes.
February 12, 2008 Notice changed office hours (above).
February 11, 2008 I have now done the Animation GUI assignment, and have a page of observations.
February 6, 2008 In case you are having trouble understanding what the binary tree methods are supposed to do, I have provided some examples.
February 5, 2008
pizza

Finally! Another pizza party!
...and this time with hoagies, too

Thursday February 7, 6:00 - 7:30
Levine 307

Who is invited: All current and former MCIT students and faculty, and students taking MCIT classes. OK to bring a guest.

February 2, 2008 Correction: In BinaryTree.hashCode(), the lines
    if (rightChild != null) {
        result += 7 * leftChild.hashCode();

should be replaced with
    if (rightChild != null) {
        result += 7 * rightChild.hashCode();


Note: To return a Set from the assigned methods, you must instantiate a HashSet, not a TreeSet. The reasons for this will eventually become clear.
January 30, 2008

Clarification #1: I asked you to try shuffling a ten element array 100 times by each of two shuffle methods, save the results in 10x10 arrays, and print and compare the results. This is not a JUnit test, it's one where you have to look at the results and make a judgment. JUnit tests should never print anything.

Clarification #2: I said you should write test methods for any helper methods you write. I did not mean this to include any helper methods in your JUnit test class. It may be a good idea to test such methods, but it's not required.

Warning: Once you call a sort method on an array, that array is sorted. So if you do something like

bubbleSort(shuffledArray);
insertionSort(shuffledArray);
selectionSort(shuffledArray);

then the latter two calls, despite the names, are not sorting a randomized array.

Suggestion: The easy way to get separate timings on the nine cases is to put each case into a separate method. Like so:

bubbleSortAlreadySortedArray(int[] array) {
bubbleSort(array);
}
insertionSortAlreadySortedArray(int[] array) {
insertionSort(array);
}
... // six methods omitted
selectionSortShuffledArray((int[] array) {
selectionSort(array);
}
(You don't have to JUnit test these methods!)

January 28, 2008 Correction: I made my shuffle1 and shuffle2 methods private. Since I also asked for JUnit tests for these methods, please change them to public.
January 25, 2008

Correction: When testing the shuffling methods, I said to "shuffle the array ten thousand times, and see how often each element ends up in each location" Make that "one hundred thousand (100000) times," in order to get the expected value of approximately 1000 in each location of your 10x10 array.

(I had it right the first time; 10 numbers sorted 10000 times, distributed over 100 cells in a 10x10 array, gives an average of 1000 in each cell.)

January 23, 2008 Clarifications:

I wrote the Fraction class for you--the only change you are supposed to make in it is to throw an exception for division by zero. This should be done in the constructor. (You could also do it in the divide method, but that would be redundant.) Also note that throwing an exception does not mean that you should catch the exception--if this isn't clear, you need to review exceptions and exception handling.

I did talk about factory methods in class, but I never meant to imply that you should replace the Fraction constructor with a factory method. Please leave all the method signatures the same! Otherwise you will make it much more difficult for us to test your JUnit methods.

You are expected to test the public String toString() method in the Fraction class. However, your test method cannot be public void toString()--do you see why? You must give the test method some other name, say, testToString.

NetBeans, it turns out, likes to keep its JUnit tests in a different package from the code being tested, and that is causing some problems. If you like, you can change the greatestCommonDivisor method to be public access instead of default (package) access.