Monday, November 18, 2013

Beyond Linked Lists: The Skip List

Illustration of a skip list.  Note that the number of forward pointers per node is itself dynamically allocated.
Students who want exposure to data structures more advanced than a simple linked list might enjoy the skip list.  A skip list is a probabilistic data structure that looks a bit like a linked list, but behaves like a self-balancing binary tree that makes insertion and deletion relatively simple and fast.  If you want to know about a self-balancing tree that is challenging to implement, go try a red-black tree.  This spirit of the data structure turns up every now and then, such as in distributed hash tables used in peer-to-peer file sharing among other things.

"Skip Lists: A Probabilistic Alternative to Balanced Trees" by William Pugh, Communications of the ACM, June 1990.

Monday, November 11, 2013

Verdict on Student Feedback About EECS 280

A couple weeks ago, we surveyed the students in EECS 280 to get feedback on how to improve the operation of the course after we received complaints about long wait times (i.e., hours) for meeting with instructors.  About 620 students registered for the course with two faculty, 13 TAs (of which 6 are quarter time), and 4 graders to cover three lecture sections, 16 discussion sections, approximately 25 office hours, nearly 24x7 coverage of the piazza forum, and grading each week. Taking into account part-time staff (1 faculty + 1 double-time faculty + 7 full TAs + 6 1/2 TAs approx= 13), there is effectively a 620:13 ratio of students to instructors or 47:1.

Here's the original survey, and the results.  Short story: we agree the wait times are too long, and we'd like to see improvements in the student-to-instructor ratio.  In the meantime, we are load balancing office hours to increase availability at certain peak times (at the expense of decreasing availability for hands-on exercises in the classroom and other things).  Unfortunately, we were denied requests for additional graders.  Human resources requested that we instead divert TA hours from in-person student interaction to grading homework.  Human resources further admonished the staff when one TA accidentally exceeded the allowable hours.  We're trying to figure out ways to do more with less.

The data, please:
The data indicate that a small number of students experienced excruciatingly long wait times.
At busy times, the more typical wait is about an hour.

Data indicate that very few students are willing to accept "group" office hours to cut down on wait times.
It seems that students strongly prefer 1-1 debugging sessions because of the personal nature of individual programming assignments.

The data are clear: Students feel overwhelmingly that they could perform better if staff office hours were more accessible.  We have rebalanced office hours to address this short term problem, but the long-term solution seems to require more instructional staff.
Surprising to the staff, the data indicate that students overwhelmingly prefer the whiteboard over the chalkboard.  Boo!!
The data seem to indicate a toss up.  Before the survey, a number of students wrote rather strongly that the slides put them to sleep.  We were asked to cut down on the use of slides (to which we agree) during lecture, but it seems a majority of students prefer slides over the blackboard.  We surmise that students who watch recorded lectures prefer the slides because the boards are illegible via the camera, but we have no data to support this hypothesis.

Sunday, November 10, 2013

Euchre Code Base

We were curious how much euchre code was collectively written by students in EECS 280. Thanks to UNIX pipes and this handy command-line (you might find this type of command useful in the future): 
find . -name '*.cpp' | xargs wc -l
We found that students submitted 555,285 lines of code (including comments and newlines).  The staff solution to the euchre project is 747 lines of code, of which about 200 are comments and newlines.  So the class collectively wrote more code than is found in a typical pacemaker or the Quake 3 video game engine, but significantly less code than reportedly behind the website.  However, there is skepticism whether the website truly has 500 million lines of code (and by what measure).  Summary: the less code you have, generally the easier to test.
"According to one specialist, the Web site contains about 500 million lines of software code." - NY Times.