Early in my graduate school days, I once spent a couple of days poring over code listings trying to find the cause of a mysterious bug. Eventually I discovered that the code had a "1" somewhere it should have had an "l". (Or maybe it was the other way around.) With the low-resolution displays and line-printers we were using at the time, it was almost impossible to distinguish between these characters.

I remembered this episode last week when I noticed this comment in some Image Processing Toolbox code:

/*
 * This is the algorithm "Create L from Candidates," bottom of column 2,
 * page 532 to top of column 1, page 533.  The following changes have
 * been made to the printed version of the algorithm:
 *   -  Script "L" replaced by "ell"
 *   -  "r" replaced by "c"
 *   -  "l" replaced by "p" (because SLE never names variables "l"!)
 *   -  "c" replaced by "num_candidates"
 *   -  fixed typo in paper:  "RemoveL([k-1],w,r)" should have been
 *      "Remove(L[k-1],L[k],w,r)."
 */

Yes, that's right - I was so frustrated by that grad school experience that I've never used a lowercase "l" as a variable name since then!

The last bullet in the comment highlights a difficult debugging issue. When you are implementing an algorithm based on a published description, and the implementation doesn't work, the problem might just be in the published description and not in your code. In this particular case, it was clear that the paper had a typo because the original text didn't make sense in context. Sometimes, though, you just aren't that lucky.