My problem with computer science pseudocode
beauty-of-imagination.blogspot.co.uk
My problem with computer science pseudocode
1–10 of 19 posts
Re: My problem with computer science pseudocode
#2If you're looking for algorithms with real code, Sedgewick is pretty good.
http://www.amazon.com/gp/product/032157351X
Disclaimer: I haven't actually seen this edition, which uses Java. My old edition uses C.
Disclaimer #2: I still look into my copies of Sedgewick and Knuth fairly regularly. CLR(S), not so much. Your mileage may vary.
Re: My problem with computer science pseudocode
#3I remember going through Introduction to Algorithms back in high school. Not only I had problems with understanding it in general but in addition it was a translation. A very bad translation.
I'm a big fan of The Algorithm Design Manual by Skiena. This is the book that I usually recommend.
Re: My problem with computer science pseudocode
#4CRS book is okay... but it's way too complex for undergraduate. I rather listen to lectures than reading this book. I think even talent programmers have to agree with me that CRS is a reference, not a textbook for teaching. It's only for people who have done enough algorithms and data structure and want a reference book.
Re: My problem with computer science pseudocode
#5This is a general problem with academic books/papers. Authors rarely focus on making their work as easily understandable as possible. Instead, the goal almost seems to be the opposite -- how obscure sounding can I make this paper (so that I appear really smart) while still maintaining correctness?
It's very frustrating. We get it: you're smart. Now quit using words like "complecting" and quit using elliptic modular forms when addition and subtraction would suffice instead.
EDIT: Alright, so the downvotes indicate my post was a little rant-ish (I don't get downvoted much on here so it disturbs me when I do). I apologize for that. There were a few papers that I read recently where some of the words were very obtuse and I couldn't think of a good reason for choosing those over simpler and more communicative words. "Authors rarely..." was likewise an exaggeration.
But I do stand by my point that clear communication is something I think technically-oriented people should focus on. Perhaps courses could be offered where you describe a complex subject and then others in the class comment on what areas were the most confusing. This is different than a peer-review process in that you're not necessarily focusing on the accuracy of the material but the clarity of its expression.
Re: My problem with computer science pseudocode
#6I have to diagree with your PoV for recursion. I personally don't have any problems if an alogrithm is iterative or recursive, specially if the recursivity is as simple as in your example. In fact, in such cases recursivity is even simpler to understand than iteration IMHO.
Re: My problem with computer science pseudocode
#7I have to diagree with your PoV for recursion. I personally don't have any problems if an alogrithm is iterative or recursive, specially if the recursivity is as simple as in your example. In fact, in such cases recursivity is even simpler to understand than iteration IMHO.
I came here to say something similar. I would go further and assert that once you're comfortable with recursion it's nearly always preferable where reasoning about execution is the primary concern. Discarding the mental overhead associated with index accounting and temporary variable state has a lot of value.
Re: My problem with computer science pseudocode
#8I read the book much better than Rodrigo's Python code. The book writes about "max-heaps." Rodrigo tries to rewrite is to apply it on an array, uses confusing names where simple one letter names suffice, rewrites tail recursion which is anyway obvious that it can be substituted with a while loop, producing, at least for me, much less readable code. By the way, even in the production code I do use one letter names for local variables in the functions that span a few lines and where their use is obvious.
Re: My problem with computer science pseudocode
#9This is a general problem with academic books/papers. Authors rarely focus on making their work as easily understandable as possible. Instead, the goal almost seems to be the opposite -- how obscure sounding can I make this paper (so that I appear really smart) while still maintaining correctness? It's very frustrating. We get it: you're smart. Now quit using words like "complecting" and quit using elliptic modular f…
I understand where you're coming from (in your frustration at least), but where most academic papers are concerned this isn't an issue of attempting to sound "smart", it's an issue of audience.
The audience of most academic writing is other experts in the same field, and the goal is to convey the contribution. Without the necessary abstractions, and therefore the requirement of understanding them, the task of composing works on meaningful contributions would be absurdly difficult.
Re: My problem with computer science pseudocode
#10Unfortunately I can't see the pseudo code you are criticizing. But I have a degree in CS and I'm familiar with the notion of pseudo code and the way it's usually written in academic papers.
I agree with you that the way code is written matters a lot in practice. But in academic papers, usually the idea, the runtime and the correctness of algorithms have a higher priority than implementation details. Sure, you can write more readable pseudo code, but I haven't come across an algorithm in a paper that I wasn't able to understand. In fact, I do often like the way it is written.
Who says that computer scientists are necessarily great programmers? That's not the case. Universities (at least in Germany) doesn't teach you how to be an "elite grade developer", as you said. They teach fundamental concepts in computer science.
Why recursion? If you approach a problem with mathematics then thinking in terms of functions and recursion is very natural. Recursion is a fundamental mathematical concept and it's often easier to reason about recursive functions (inductive proofs).