has anyone followed sedgewick's "algorithms in c parts 1-4"?

[ben]

has anyone got or read this book: robert sedgewick "algorithms in c
parts 1-4"?

i'm having an absolute nightmare with the book. amoung other things i'm
trying to construct the necessary support files needed to make use of
the example programmes. (support files as in .h .c files that are
#included and used to compile with).

the programmes are designed to use abstract data types so that you can
drop in different versions of the support files and the main programme
will work happily with the various types (support files that handle
types int, double, variable length strings etc.)

the different implementations and headers of the different support file
types are fragmented throughout the text (sometimes not even code, but
just an english description) and are also incomplete -- some bits that
are required by a program's code don't even have english descriptions
so far as i can tell. so far i've been unable to find a complete set of
any of the support files for any of the types -- some of the parts of
the support files are just assumed and the reader is expected to do
kind of detective work to construct the necessary codewhich is
*completey* crap imo -- it should be on a plate but it's not. i'm
getting severely frustrated because the algorithm side of the book
looks good but i can't get past this basic sort of packaging/logistics
part. (why on earth isn't it made completely obvious? anyway, it
isn't.)

if anyone's followed that book and still have some/any of the code
around, could you post it please? it'd be really appreciated. (a full
set of support files for any one of the types (int, double, variable
length string) would be fantastic. i'm talking about Item.h and ST.h
and also probably Item.c and whatever else if there's more, applicable
in particular to the search section -- chapter 12 onwards).

if not i'm going to post what mess i have so far. now there's threat
you don't want me to follow through on. :)

the book's code on sedgewick's website is of no use (only to save you
typing) -- it's an exact copy of the code in the book, and is in fact
worse, as there are no indications what so ever of names/labels for the
modules of code.

thanks again, ben.

[Gregory Toomey]

ben wrote:

has anyone got or read this book: robert sedgewick "algorithms in c
parts 1-4"?

i'm having an absolute nightmare with the book. amoung other things i'm
trying to construct the necessary support files needed to make use of
the example programmes. (support files as in .h .c files that are
#included and used to compile with).

the programmes are designed to use abstract data types so that you can
drop in different versions of the support files and the main programme
will work happily with the various types (support files that handle
types int, double, variable length strings etc.)

the different implementations and headers of the different support file
types are fragmented throughout the text (sometimes not even code, but
just an english description) and are also incomplete -- some bits that
are required by a program's code don't even have english descriptions
so far as i can tell. so far i've been unable to find a complete set of
any of the support files for any of the types -- some of the parts of
the support files are just assumed and the reader is expected to do
kind of detective work to construct the necessary codewhich is
*completey* crap imo -- it should be on a plate but it's not. i'm
getting severely frustrated because the algorithm side of the book
looks good but i can't get past this basic sort of packaging/logistics
part. (why on earth isn't it made completely obvious? anyway, it
isn't.)

if anyone's followed that book and still have some/any of the code
around, could you post it please? it'd be really appreciated. (a full
set of support files for any one of the types (int, double, variable
length string) would be fantastic. i'm talking about Item.h and ST.h
and also probably Item.c and whatever else if there's more, applicable
in particular to the search section -- chapter 12 onwards).

if not i'm going to post what mess i have so far. now there's threat
you don't want me to follow through on. :)

the book's code on sedgewick's website is of no use (only to save you
typing) -- it's an exact copy of the code in the book, and is in fact
worse, as there are no indications what so ever of names/labels for the
modules of code.

thanks again, ben.

The code is available online & I used it years ago. Look.

gtoomey

[ben]

In article <2v************ *@uni-berlin.de>, Gregory Toomey
<no****@bigpond .com> wrote:

ben wrote:

the book's code on sedgewick's website is of no use (only to save you
typing) -- it's an exact copy of the code in the book, and is in fact
worse, as there are no indications what so ever of names/labels for the
modules of code.

thanks again, ben.

The code is available online & I used it years ago. Look.

gtoomey

i can see code in the book and i can see all of that code repeated on
his website. the problem is that that code (book or website -- they're
both exactly the same) does not allow you to run the programmes as is.
the necessary extra files are incomplete and fragmented throughout the
book, some of which isn't even in code but just english, for example
"...we extend the Item concept ... such that items contain keys of type
Key". nowhere, in code (in book or website), is Key defined or typed or
whatever so that sentance is as far as Key gets -- and there's other
bits that never even get described in english -- they're just missing
(yes they're just defines but all adds to the mess/my confusion -- why
should they be missing?). and it's even more confusing because the
different fragments of the code which need putting together that are to
be included by the programmes are a mixture of the various data types
(as he's using abstract data types, one for double, one for int etc).
there doesn't seem to be a full set of support files for any one of the
abstract data types.

so the organisation/packaging, and some of the gaps in the code, is not
obvious at all to me. it's a shame i'm getting stuck and frustrated on
what shouldn't be an issue -- it should be on a plate but isn't

it's not a question of me not having looked, it's a question of me not
being able to reconstruct and fill in the gaps and know how to organise
it.

:( most frustrating

[bazad]

ben <[e-mail]> writes:

In article <2v************ *@uni-berlin.de>, Gregory Toomey
<no****@bigpond .com> wrote:

ben wrote:

the book's code on sedgewick's website is of no use (only to save you
typing) -- it's an exact copy of the code in the book, and is in fact
worse, as there are no indications what so ever of names/labels for the
modules of code.

thanks again, ben.

The code is available online & I used it years ago. Look.

gtoomey

i can see code in the book and i can see all of that code repeated on
his website. the problem is that that code (book or website -- they're
both exactly the same) does not allow you to run the programmes as is.
the necessary extra files are incomplete and fragmented throughout the
book, some of which isn't even in code but just english, for example
"...we extend the Item concept ... such that items contain keys of type
Key". nowhere, in code (in book or website), is Key defined or typed or
whatever so that sentance is as far as Key gets -- and there's other
bits that never even get described in english -- they're just missing
(yes they're just defines but all adds to the mess/my confusion -- why
should they be missing?). and it's even more confusing because the
different fragments of the code which need putting together that are to
be included by the programmes are a mixture of the various data types
(as he's using abstract data types, one for double, one for int etc).
there doesn't seem to be a full set of support files for any one of the
abstract data types.

so the organisation/packaging, and some of the gaps in the code, is not
obvious at all to me. it's a shame i'm getting stuck and frustrated on
what shouldn't be an issue -- it should be on a plate but isn't

it's not a question of me not having looked, it's a question of me not
being able to reconstruct and fill in the gaps and know how to organise
it.

:( most frustrating

I have Part 5 only. I agree, that the algorithms are not complete. I
had to fill the missing parts myself. This forces to actually
understand the book, istead of just coping the code.

[ben]

In article <1100564873.wBA smficAl63DG5bpq +hkw@teranews>, bazad
<no****@noreply .not> wrote:

ben <[e-mail]> writes:

....

it's not a question of me not having looked, it's a question of me not
being able to reconstruct and fill in the gaps and know how to organise
it.

:( most frustrating

I have Part 5 only. I agree, that the algorithms are not complete. I
had to fill the missing parts myself. This forces to actually
understand the book, istead of just coping the code.

but the type of code that's missing is packaging / setup code,
essential but periferal to the workings of the algorithm. even if
missing lines of code and the act of filling in the gaps, second
guessing, is a good way to teach/learn (which i'm not sure about), the
area that the missing parts cover are in an unsuiteable book. they
would be more appropriate in a 'how to programme in c' book than an
algorithm book.

the hand waved / missing parts of code has forced me to get bogged down
with and concentrate on stuff other than algorithms.

i personally don't think the author left out these pieces of code for
tutoring purposes -- i think lazyness/lack of thoroughness was the
reason. if you found it a help in learning about algorithms that's
great, but i'm finding it quite unhelpful and frustrating.

(btw, a positive thing to say about the book: the diagrams: top quality)
anyway, i still would really appreciate it if anyone could post a full
working set/collection of the necessary code modules for any one of the
programmes (preferably from the 'searching' section (ch12 onwards)
involving Item.h and ST.h etc for any one of the data types) in
'algorithms in c parts 1-4' by sedgewick. (i'm not talking about the
exercises, but the example programmes)

thanks, ben.