Comments on: Algorithms questions are hard, but that’s inherent in the subject

By: Daniel Stutzbach

Daniel Stutzbach — Tue, 05 Jan 2010 09:28:38 +0000

Nearly all of my students were able to complete the compare-sorting-algorithms assignment. Many had errors in one or more of their programs, and a few students were unable to get some of the algorithms working at all. IIRC, I gave them two weeks to do it. I provided the bubble sort implementation, the random data for several values of n, detailed instructions on how to validate the correctness of their algorithm, and on how to measure execution time. We had already covered insertion sort, quicksort, and mergesort in class, and the course textbook provided pseudo-code. It was easily the most straightforward programming assignment I gave (but writing code wasn't really the main purpose of the exercise).

YMMV.

If you try Skiena, I'd like to hear how that works out. I used the first edition as reference book for finding algorithms to solve programming competition problems on more than one occasion.

By: Peter Boothe

Peter Boothe — Tue, 05 Jan 2010 09:03:09 +0000

True! I took at least one of those algorithms courses myself!

I like your “build a few and compare” approach. I worry that it will fall afoul of the “students can't code fast enough” problem. As for books, I would like to take this opportunity to recommend “Algorithm Design” by Kleinberg and Tardos, which served me quite well this term. I am going to investigate the possibility of using “The Algorithm Design Manual” by Skiena next term, but “Algorithm Design” was light-years ahead of CLRS and a much better reference once the class was over than “Algorithms” by Dasgupta et al. (which is perhaps the most readable algorithms book I've yet found)

“Algorithms” is a *fantastic* book however. I recommend checking it out online at http://www.cs.berkeley.edu/~vazirani/algorithms...

By: Daniel Stutzbach

Daniel Stutzbach — Tue, 05 Jan 2010 08:55:42 +0000

I think there's a third way to teach an Algorithms class, and that's to teach it as a math course where you spend all of the time analyzing the performance of algorithms and no time writing actual code. Both of the Algorithms classes I took were like that.

Needless to say, I'm a fan of the “why” style you're describing.

When I taught the Algorithms course at SMU as an Adjunct a few years back, I tried to give the students a framework for categorizing algorithms (greedy, dynamic programming, and so forth) and throw all kinds of problems at them to give them a sense for which kinds of problems could be solved with which kinds of algorithms. I also tried to give them a sense for the benefits and drawbacks of different kinds of algorithms (e.g., greedy algorithms are easy to write and fast! Oh, but if you use one you have to write a proof of correctness…)

At one point I assigned the students a performance study where they had to implement several different sorting algorithms (bubble sort, insertion sort, quicksort, mergesort, and “call the language's built-in sort function”) and measure their run time for many different n. Suddenly all of that abstract big-O stuff became concrete as they twiddled their thumbs waiting for bubble sort and insertion sort to complete. It was cool watching that “click” for them.

I think “the language's built-in sort function” may have also humbled a few egos.