Robert Sedegewick (Algorithms in C)
JS
can see that its from 1997.
But if I buy the bundled version (you also get pt. 5 Graph Algorithms 3rd
edition) I can see its from 2001.
Are the first book in the bundled version (pt. 1-4) an updated verison of
the the same book from 1997?
JS
Jerry Coffin
At least IMO, you're better off ignoring _all_ editions of Sedgewick's
books. For a good book on algorithms, I'd consider _Introduction to
Algorithms_ by Cormen, Lieserson and Rivest. I believe the current
edition has another author as well, but I don't remember his name
offhand.
IMO, about the only way Sedgewick's books are useful in learning
programming is if you burn them to produce enough light to read
something else.
--
Later,
Jerry.
The universe is a figment of its own imagination.
JS
"Jerry Coffin" <jco...@taeus.com> skrev i en meddelelse
news:1115937504.2...@f14g2000cwb.googlegroups.com...
Could you be a bit more specific?
Jerry Coffin
[ recommendation against Sedgewick's books elided ]
> Could you be a bit more specific?
Sure. First of all, IMO he's just a lousy writer -- I once went to his
book to check one detail of an algorithm I generally understood. By the
time I'd read his explanation, I not only hadn't figured out what I
needed, but was even confused about the parts I'd previously
understood!
Second, he seems to choose the algorithms he covers based more on his
personal opinion than on what you're likely to want to know -- for an
obvious example of this, he has a chapter that claims to be devoted to
B-trees -- but really covers something entirely different (which
happens to be a variation of an algorithm he invented instead).
To go with this, he routinely claims that the algorithms he otherwise
ignores are "more complicated", even when (at least IMO) precisely the
opposite is the case.
Third, his treatments are usually too incomplete to be really useful --
while he discusses how to construct various kinds of balanced trees, he
fails utterly to discuss how to _delete_ a node -- which certainly is
NOT so trivial that it deserves to be completely ignored.
Likewise, he claims to cover parsing in a mere 12 pages -- coverage is
so minimal that it's pointless to have included it at all. In fairness,
he admits that "Our brief description only skims the surface of the
issues involved." -- but pointing out the problem doesn't excuse it.
Even if we excuse all of the above, he also attempts to simplify some
subjects to the point that what he says is really wrong. Just for
example, his treatment of file compression only covers the two-pass
static version of Huffman compression, with no mention of the other
variations. He makes statements that really only apply to this
variation as if they applied to Huffman compression in general. For
example, he claims that when using Huffman compression, it's necessary
to store or transmit the Huffman tree along with the compressed data.
While that's true for the variant he covers, it's NOT true at all for
some other variants.
I divide algorithm books into three major categories. The first I'd
call recipe books -- basically, how to implement well-known algorithms,
usually in a specific language. There are quite a few books in this
category, though large chunks of many of the older ones devoted to C++
are rendered obsolete by the algorithms in the standard library.
The second major category would be a simple guide book, such as for a
manager who won't be implementing the algorithms at all. This should
cover as many algorithms as possible, discussing trade-offs and
providing guidance about which to use when. I'm not sure I've seen a
really good book in this category, but what I'm thinking of would be
roughly on the order of a "CRC Handbook of Algorithms" (and maybe
exactly that exists).
The third category would be a real computer science textbook. This
would cover algorithm analysis and go into considerable detail about
the algorithms being covered in the process. Examples here would be
Knuth's _The Art of Computer Programming_ and the previously mentioned
_Introduction to Algorithms_.
With care, a good computer science text book can be used to cover
either of the other areas reasonably well -- but it's clumsy. These
will tend to lack coding details and summaries tend to be buried in
analysis the point that you have to be highly selective to use it as a
guidebook.
Looking at these categories, Sedgewick:
skips too may details to be a useful recipe book.
ignores too many algorithms to be a useful guidebook.
glosses over analysis too much to be a text book.
It's a failure no matter what you want. Most people who think they want
his book want a computer science text book, in which case my previous
recommendation stands.
osmium
> [ recommendation against Sedgewick's books elided ]
<snip>
> Third, his treatments are usually too incomplete to be really useful --
> while he discusses how to construct various kinds of balanced trees, he
> fails utterly to discuss how to _delete_ a node -- which certainly is
> NOT so trivial that it deserves to be completely ignored.
I have two versions of the Sedgewick book, the language neutral version and
the C++ version and I don't like either of them. I have never tried, as
Jerry has, to analyze *why* I don't like them. But the omission of how to
delete a node in a tree is simply inexcusable. It is relatively difficult
and not at all obvious. That one omission is sufficient grounds to take the
book off the list of candidates. There is no subjectivity here, node
deletion is either covered or it is not.
That's a great review, Jerry, lot's of substance to it!
Of books that are actually available for purchase in book stores, I think
Cormen is the current favorite. I have had it on loan and think I liked it.
Some day when I need to round up a book order, to get free shipping or
something, I will probably buy it.
Anand Hariharan
Jerry Coffin wrote:
(...)
>
> For a good book on algorithms, I'd consider _Introduction to
> Algorithms_ by Cormen, Lieserson and Rivest. I believe the current
> edition has another author as well, but I don't remember his name
> offhand.
>
Is this a hard-bound huge book (>1000 pages), with all its algorithms
explained in pseudo-code and one or more authors affiliated to MIT? I
remember coming across such a book when I was browsing through books in
a book store; hence the question.
> IMO, about the only way Sedgewick's books are useful in learning
> programming is if you burn them to produce enough light to read
> something else.
>
Interesting to hear that (As I write this, I also read your other post
where you elaborated your statement above). Glassborow (known for his
scathing reviews) gives Sedgewick's books a pretty decent review:
http://www.accu.org/bookreviews/public/reviews/a/a003133.htm
- Anand
Jerry Coffin
> Jerry Coffin wrote:
> (...)
> >
> > For a good book on algorithms, I'd consider _Introduction to
> > Algorithms_ by Cormen, Lieserson and Rivest. I believe the current
> > edition has another author as well, but I don't remember his name
> > offhand.
> >
>
> Is this a hard-bound huge book (>1000 pages), with all its algorithms
> explained in pseudo-code and one or more authors affiliated to MIT?
> I remember coming across such a book when I was browsing through
> books in a book store; hence the question.
Yes, that all sounds correct. Along with Ron Rivest being a professor
at MIT, it's published by MIT Press, which may have helped that stick
in your mind.
[ ... ]
> Interesting to hear that (As I write this, I also read your other
> post where you elaborated your statement above). Glassborow (known
> for his scathing reviews) gives Sedgewick's books a pretty decent
> review:
> http://www.accu.org/bookreviews/public/reviews/a/a003133.htm
Yes, Francis and I pretty clearly disagree on this one. For that
matter, he has also reviewed _Introduction to Algorithms_:
http://www.accu.org/cgi-bin/accu/rvout.cgi?from=0pb_MIT_Press&file=i003025a
and mostly disagrees with me about it as well. Unfortunately, I find
his review somewhat wanting. He says, for example, that:
However if you want a more pragmatic approach and think in
terms of algorithms expressed in pseudocode then leave this
book on the shelf.
To me, this seems misleading at best -- while I suppose there may be
_some_ algorithm in the book for which pseudocode isn't presented (it
is a _big_ book), the vast majority of algorithms certainly DO include
pseudocode. Oddly no such comment is made about Sedgewick's books, even
though he really does NOT present pseudocode for most algorithms.
In fairness, I do agree with Francis that Cormen, et al use notation
that's unfortunate and off-putting. Francis seems to consider this
justification for barely short of outright condemnation of the book. I
find it a minor problem at most. For one thing, this notation is used
almost exclusively in the analysis sections, which are clearly marked
so they're easily skipped over by those interested primarily in the
more "pragmatic" sections, such as pseudocode presentations of the
algorithms themselves.
Just for example, deleting a node from a red/black tree is covered in
section 13.4. Top-level pseudocode is on page 288. Pseudocode for
fixing up the tree (reblancing) is on page 289. Diagrams of deletion
are on page 291. At the top of page 293 we find a heading of "Analysis"
-- which, as we'd expect, talks about computation complexity -- but in
this section the only "special" notation we find is the well-known
big-Oh.