Log in

No account? Create an account

Previous Entry | Next Entry

Sep. 1st, 2007

So, continuing in the vein of the last entry, I just can't grasp the practicality of memorizing algorithms. There's TOO MANY of them. I think it is useful to understand what each can be used for, and when it is appropriate to use them. But I don't see why anyone should go to the trouble of memorizing algorithms when there are zillions of references, both off- and online, that are available if someone needs the pseudocode or an implementation.

For example, Cormen's algorithms text has over 1000 pages. Knuth's texts consist of three volumes (plus some new sections). There are other algorithms books that get decent reviews, such as Aho's and Baase's. Beyond that, there are books that deal in specialized algorithms, such as Lynch's or Bertsekas' for distributed and parallel computation. I haven't even touched all of the books with algorithms written in specific languages, such as Sedgewick's.

And let's get real here. We're talking about Google, which can (and should) be used to reference information that is available on the web. I just don't buy that because of "chaos", people need to be able to quote some algorithm by heart. As I understand it, all the offices are enabled with fast wireless LANs, and people can get computers when they need them, so if there is a need for a quick lookup of an algorithm, it's only a few keystrokes away for any Googler.


( 7 comments — Leave a comment )
Sep. 2nd, 2007 01:02 pm (UTC)
I share your opinion on this. I have a decent memory, and pretty good long term retention, but that's more out of sheer interest than practical necessity. A former boss of mine at Merrill Lynch told me about a time he was interviewed for a job early in his career. The interviewer asked him for a specific formula, and left the room for a couple of minutes. My boss found the formula in one of the interviewer's reference books, and said as much when the interviewer returned, essentially making your point.

One of the reasons I left med school was because there the ratio of memorization to conceptualization was far too high for my tastes.
Sep. 3rd, 2007 10:43 pm (UTC)
I wonder if software engineering is becoming more like medicine. More later on this, perhaps.
Sep. 2nd, 2007 03:47 pm (UTC)
This was one of my big complaints about intro organic chemistry, which I failed. Why did we have to memorize the reactions and catalysts when it would be trivial to look them up?
Sep. 3rd, 2007 04:51 am (UTC)
Why is organic chemistry difficult?
I never took orgo, and I don't remember much of it from the other chem classes I took, so it's hard for me to say what's difficult about it. But it seems that there are a core set of principles one must memorize, which everything else builds upon. So it's a reductionist type of discipline, unlike algorithms. It seems like it might be like Euclidean geometry. What did you think of that when you took it? Did you think there was a lot to memorize?

I found a couple of interesting web sites discussing how orgo can be difficult, here and here.

As another comparison with algorithms, I remember when I was an undergrad, people who took orgo used problem solving books published by Schaum and REA. These books seemed to track the material presented in the classes, enough that these folks did well. There were not such problem solving books on algorithms (or quite a few other computer science subjects like 6.034), and what little practice/review material was out there did not track the classes very well.
Sep. 2nd, 2007 08:08 pm (UTC)
It smacks of a dickegosize contest.
Sep. 3rd, 2007 05:13 am (UTC)
Yeah, I'm with you. I care about how a candidate thinks and researches, not what he currently has swapped in. I mean, yeah, there has to be a certain basic level of knowledge, but my answer to algorithms questions like that would be "pass me your Knuth" or "I can have that for you in a couple minutes if you let me use the internet".
Sep. 5th, 2007 07:05 am (UTC)
I decided to give myself a little quiz today. I was going to try to implement binary search in Perl without documentation. (It's been a few weeks since I've written more than a couple of lines of Perl.) After a while I realized there were some things I didn't remember, e.g. what the command was for creating a list (array) from numbers taken from the standard input; how to get the index of the last element (without iterating through all of them); whether the result of dividing one integer by another is always an integer. I didn't finish because there were other things I had to do, but it was harder than I thought it would be (although it would have been easy if I'd allowed myself to use documentation).

Part of the argument I'm making here is at what price comes making sure I can code this in any of the languages I've listed on my résumé. What I am not covering instead that might be asked of me in an interview? How can I figure out what relative importance this has to everything else I might need to know?
( 7 comments — Leave a comment )