I have posted the tree searching lecture (sorry, thought I already had).

The second midterm will cover tree searching; it will not cover graphs.

We will have the second midterm next week, either Tuesday or Thursday. By Thursday morning, please mail me your preference.

Send email with the Subject: Second Midterm in CIT594

In your email, answer the following two questions:

• Which day you prefer, Tuesday or Thursday
• If you cannot make it to class one of those days, please say so, and tell me why.

If you don't vote, you don't get to complain about the outcome!

Earlier I gave you a file, LineReader.java. Here is an almost equally easy-to-use class, SimpleIO.java, that you can use in current and future assignments. The main difference is that each of the methods might throw an IOException, so you have to embed the calls in a try...catch statement

Here are the methods supplied in SimpleIO.java; I think what they do should be pretty obvious.

• public static ArrayList<String> load() throws IOException
• public static void save(ArrayList<String> lines) throws IOException
• public static void saveAs(ArrayList<String> lines) throws IOException
• 
  

My office hours this week:
Wednesday 11:00-12:00 and 1:30-3:00.
Thursday 3:00-4:00
Friday 11:00-12:00 and 3:00-4:00

One of our MCIT instructors, Diana Palsetia, will be leaving us next year.

This week we have two applicants coming in to interview for her position. I would appreciate it if you could attend their talks and give me your opinions.

Chris Murphy, Wednesday, March 24, 6:00 in 307 Levine.

David Nellans, Thursday, March 25, talk at 1:30-3:00, Skirkanich Auditorium.
Pizza party at 6:00.

I have posted some Clarifications to the Library assignment. I don't think there's anything really surprising in here. There are also some hints on reading JUnit output.

As I said I would, I have also posted some unit tests for the Library assignment, in a file called LibraryTests.zip. Download this file and unzip it in your library directory; Eclipse should recognize it automatically. These are the same tests we will use in grading your assignment (though we will also look at programming style and the user interface).

You can run the test files one at at time, or you can run AllTests. You are likely to find a great many failing tests, but don't let that discourage you. Just pick the easiest one to fix, fix it, run the tests again, and move on. The names of each test should give you some clue what it is testing, but if it isn't obvious, read the test code.

Average score on first question (reading short Python methods) was 38%. If that question is ignored, the average on the remaining questions was 59%.

I have finally put up the partner evaluation forms for:

They would have been up earlier, but I had technical difficulties (as in, my program crashed.) Remember, these are required and confidential. Please wait to fill out the Hearts evaluation form until you have completed that project.

Addition to Library assignment:

• The Book class should have a def set_due_date(self, due_date) method.

If you understood what I've been saying about an object having responsibility for it's own data, the need for this method should be evident. However, no one has noticed/asked me about this omission.

Because this addition is being posted so late, it is an optional change.

Corrections to Library assignment (sorry, but these are necessary).

• Change the header of the Patron constructor to def __init__(self, name). Patron objects do not need, and should not use, the library parameter.
• Change what the issue_card method in Library does:
  
  Issues a library card to the person with this name. (What this actually does is create a Patron object, and save it as the key in a dictionary. The value should be the empty set, representing the books currently checked out to this patron. creates a Patron object, and saves it in a dictionary. The patron's name should be the key, and the Patron object itself should be the value.) No patron should be permitted to have more than one library card.
  
  This change avoids a number of problems.
  

Notes on 06-Library assignment:

• The search command should do a case-insensitive search. That is, a search for "farm" should find "Animal Farm". However, the results should be presented to the user with correct capitalization, not in all lowercase or all uppercase.
• There are multiple copies of some books (such as Animal Farm). Your search should present only one of these to the user; it shouldn't list every copy.
• Since I said that the patron will have a set of books checked out, I guess that means that the patron cannot check out multiple copies of the same book. (I guess I should have used a list or a bag.) Don't worry about this case, we won't test for it.
• Here's the file of books that I promised I would supply: books.txt. It's a list of 2-tuples of strings.

Special MCIT talk
  AFTER THE REVOLUTION:
  Coping with success in an Open Source World
Eric S. Raymond

Heilmeier Hall (Towne 100)
6:00-8:00pm, Wednesday, February 24

Clarification: I've gotten several questions about whether you should check for invalid input in the 05-Array Operations assignment. The short answer is: In this assignment, you should raise a RuntimeError in those cases where I explicitly said to raise a RuntimeError. You don't need to do any other checking.

The longer answer is that, in general, you should raise an exception any time where bad input will cause the function to return incorrect results. Although I may have missed some cases, most of the methods will already raise exceptions for bad input. For example, the call array_ops.unravel(5) will raise an exception when the code tries to treat 5 as an array; this will happen without you having to explicitly check for it.

Exceptions may be bad, but wrong answers are much, much worse.

There seems to be some confusion about what I mean by a "two-dimensional array." I mean a list of lists, where all the sublists are the same length.

[ [1, 2, 3],
  [6, 5, 4],
  [7, 8, 9],
  [0, 1, 0] ]

[ [1],
  [2],
  [3] ]

[[1, 2, 3]]

[[]]

[ [1, 2, 3],
  [4, 5],
  [6, 7, 8] ]

[ (1, 2),
  (3, 4),
  (5, 6) ]

["hello"]

Some of you have noticed that Python has an Array data type. I haven't talked about those, and we aren't going to use them in this course.

Remember, a good programming style is to write lots of little functions that each do a single thing, and to combine them into higher-level (but still little) functions as needed.

Be sure you understand the difference between a variable (the name of a thing) and a value (the thing itself). When you call a function, you are passing in a reference to a value, such as (for example) a dictionary. Changes made to the dictionary itself are visible in the calling function; assignments to the variable (parameter name) are not.
 def foo(dictionary):  
     dictionary['apple'] = 'red' # visible in calling function
     dictionary = { 'banana': 'yellow' } # not visible

If you would like to see your road map, here is a function display_map.py.txt (saved as a .txt file for easy downloading) you can use. It will display your cities and "roads" as a 52-line ASCII picture. It works pretty well for maps with not more than 8 or 10 cities. If two cities are very close together, one may cover up (hide) the other one; I didn't think this was worth trying to fix.

Let me emphasize that, in the Cities assignment, I have specified the data structures you should use for the directory (a dictionary whose keys are city names, and whose values are (x, y) tuples of floats), and the road_map (a dictionary whose keys are city names, and whose values are sets of city names). If you don't use these structures as arguments to and results from your required functions, you code will fail our tests, and you will not get a good grade. Don't let this happen!

As a simple test, if you print out a directory, it should look something like this:
{'a': (571.33141134282891, 95.232686018046792), 'c': (194.84529060087308, 744.20164709935136), 'b': (441.4780095248849, 466.78192883050349)}

And if you print out a road_map, it should look something like this:
{'a': set(['c']), 'c': set(['a', 'b']), 'b': set(['c'])}

This is not a change. If you have read the assignment carefully, you should already be doing this. I just don't want to see you losing a lot of points for using slightly different data structures than the ones specified in the assignment.

Corrections to Cities assignment:

All the functions that take a map as a parameter should also take the directory as a parameter. The reason is that these functions need to know the locations of cities, and that information is in the directory, not in the map. (The assignment page has been updated to reflect these changes.)

Suggested change:

The word map is the name of a Python function (notice its color in IDLE). Since you probably won't use the map function in the current assignment, it is legal to use map as the name of a variable; but it isn't good style. I suggest the alternate name road_map. (I have also made this change in the assignment page.)

Cracking the Technical Interview:
Advice for CS students on interviewing for software engineer positions

Gayle Laakmann
Thursday, February 4, 2010, 4:00pm
Wu & Chen Auditorium

Abstract

CS interviews are a different breed from other interviews and, as such, require specialized  skills and techniques.  /Cracking the Technical Interview/ will teach you how to prepare for technical interviews, what top companies like Google and Microsoft really look for, and how to tackle the toughest programming and algorithm problems. This talk will include stories from the speaker's extensive interviewing experience as well as a live "demo" of how to tackle a technical problem

About the Speaker

Gayle Laakmann (Penn CS BSE & MSE '05) is the founder and CEO of CareerCup.com and the author of "Cracking the Technical Interview" (http://www.careercup.com/book).  CareerCup is the leading source of technical interview preparation and provides a free forum with 3000+ technical interview questions, a book, a video, and mock interviews.  Gayle has worked for Google, Microsoft and Apple and has extensive interviewing experience on both sides of the table. She has interviewed and received offers from Google, Microsoft, Apple, Amazon, IBM, Goldman Sachs and a variety of other firms, and she has interviewed over 120 candidates at Google and served on its hiring committee.  She is now an MBA student at Wharton.

Email: gayle@careercup.com
Personal Website: http://www.technologywoman.com
Company Website:http://www.careercup.com

If you get a syntax error in the return eval("".join(data)) line, it is because there are illegal characters in your data file. This can happen because:

• You used a formatting text editor, such as the (badly named) TextEdit, that saves files in RTF format.
• You copied and pasted from PowerPoint. Usually this is okay, but not always.
• You moved the file to a different operating system, such as Macintosh. Different operating systems use different end-of-line characters.

Here is a revised read_sudoku(file) method that will protect you from the last of these problems:

def read_sudoku(file):
    stream = open(file)
    data = stream.readlines()
    stream.close()
    return eval(re.sub('\r', '', "".join(data)))

Need some help with your program? Saajan will be holding office hours today, 4:00-8:00, in Moore 207. Regular office hours will be established later.

It should now be possible to submit your first assignment via Blackboard. Remember, this is the only way programs will be accepted.