Malcolm's new book

[Malcolm McLean]

The webpages for my new book are now up and running.

The book, Basic Algorithms, describes many of the fundamental algorithms
used in practical programming, with a bias towards graphics. It includes
mathematical routines from the basics up, including floating point
arithmetic, compression techniques, including the GIF and JPEG file formats,
hashing, red black trees, 3D and 3D graphics, colour spaces, machine
learning with neural networks, hidden Markov models, and fuzzy logic,
clustering, fast memory allocators, and expression parsing.

(Follow the links)

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

[Eric Sosman]

Malcolm McLean wrote On 07/24/07 16:18,:

The webpages for my new book are now up and running.

The book, Basic Algorithms, describes many of the fundamental algorithms
used in practical programming, with a bias towards graphics. It includes
mathematical routines from the basics up, including floating point
arithmetic, compression techniques, including the GIF and JPEG file formats,
hashing, red black trees, 3D and 3D graphics, colour spaces, machine
learning with neural networks, hidden Markov models, and fuzzy logic,
clustering, fast memory allocators, and expression parsing.

I read only the two sqrt() replacements. The first
is bad, but at least the text says as much. The second,
supposedly superior version is broken in at least three
ways: First, it won't compile. Second, when the obvious
bug is fixed it still won't compile under C99 and won't
link under C90. And when *that* bug is fixed, a third
bug will become apparent. Sloppy workmanship.

--
Er*********@sun.com

[Keith Thompson]

Eric Sosman <Er*********@sun.comwrites:

Malcolm McLean wrote On 07/24/07 16:18,:

>The webpages for my new book are now up and running.

The book, Basic Algorithms, describes many of the fundamental
algorithms used in practical programming, with a bias towards
graphics. It includes mathematical routines from the basics up,
including floating point arithmetic, compression techniques,
including the GIF and JPEG file formats, hashing, red black trees,
3D and 3D graphics, colour spaces, machine learning with neural
networks, hidden Markov models, and fuzzy logic, clustering, fast
memory allocators, and expression parsing.

I read only the two sqrt() replacements. The first
is bad, but at least the text says as much. The second,
supposedly superior version is broken in at least three
ways: First, it won't compile. Second, when the obvious
bug is fixed it still won't compile under C99 and won't
link under C90. And when *that* bug is fixed, a third
bug will become apparent. Sloppy workmanship.

A couple more comments. The layout on the web page makes the code
nearly unreadable. And try squareroot(1.0e6).

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Flash Gordon]

Keith Thompson wrote, On 24/07/07 22:27:

Eric Sosman <Er*********@sun.comwrites:

>Malcolm McLean wrote On 07/24/07 16:18,:

>>The webpages for my new book are now up and running.

The book, Basic Algorithms, describes many of the fundamental

<snip>

A couple more comments. The layout on the web page makes the code
nearly unreadable. And try squareroot(1.0e6).

The book also confuses the concepts of integers and pointer by talking
about malloc being able to return zero. In fact, malloc cannot return
zero because that is a number, what it can return is a null pointer.

It goes on to assume that int is at least 32 bits.

Uses a non-portable method of finding out the size of a binary file
implying the only problem with the method is whether the length might be
too long to represent as a long, when in fact it is non-portable for
other more basic reasons (see the comp.lang.c FAQ).

Uses lower case names for macros. I will admit that the standard does
not mandate upper case, but it is a well known convention.

Seems to recommend against keeping library functions in separate source
files and headers. To quote:
| And we are ready to go. However often if you intend code to be passed
| about, it is not a good idea to include stdsup.h. Cut and paste the
| function into your source instead and declare it static.

It at the very least implies that everything does and always has used
IEEE format when it says:
| ... In small embedded systems, or older computers, they were often
| done in software. Whether hardware or software operations are chosen,
| the memory format is the same.
Oh, and don't forget that a UK person should reference either the UK
standard or the ISO standard in preference to the American standard.
--
Flash Gordon

[pete]

Eric Sosman wrote:

>
Malcolm McLean wrote On 07/24/07 16:18,:

The webpages for my new book are now up and running.

The book, Basic Algorithms, describes many of the fundamental algorithms
used in practical programming, with a bias towards graphics. It includes
mathematical routines from the basics up, including floating point
arithmetic, compression techniques, including the GIF and JPEG file formats,
hashing, red black trees, 3D and 3D graphics, colour spaces, machine
learning with neural networks, hidden Markov models, and fuzzy logic,
clustering, fast memory allocators, and expression parsing.

I read only the two sqrt() replacements. The first
is bad, but at least the text says as much. The second,
supposedly superior version is broken in at least three
ways: First, it won't compile. Second, when the obvious
bug is fixed it still won't compile under C99 and won't
link under C90. And when *that* bug is fixed, a third
bug will become apparent. Sloppy workmanship.

I'm pretty sure that the assert expression
in squareroot(), was an untested afterthought.

I didn't like the arbitrary termination conditions
invlolving magic numbers like 10 iterations in squareroot(),
or 0.000001 in exponent(), or 0.00000001 in logarithm().

The exponent and logarithm functions
could have been terminated through conditions
involving DBL_EPSILON.

A Newton-Raphson square root algorithm,
can be terminated more logically:

double sq_rt(double x)
{
if (x 0) {
const double c = x;
double y = c / 2 + 0.5;

do {
x = y;
y = (c / x + x) / 2;
} while (x y);
}
return x;
}

Page 55 shows pi at 3.1415926535897931160
The "1160" part, is wrong.

I uploaded some math functions written
in completely portable freestanding C code, to:

http://www.mindspring.com/~pfilandr/C/fs_math/

/* BEGIN fs_math.h */
/*
** Portable freestanding code
*/
#ifndef H_FS_MATH_H
#define H_FS_MATH_H

double fs_sqrt(double x);
double fs_log(double x);
double fs_log10(double x);
double fs_exp(double x);
double fs_modf(double value, double *iptr);
double fs_fmod(double x, double y);
double fs_pow(double x, double y);
double fs_cos(double x);
/*
** C99
*/
double fs_log2(double x);
double fs_exp2(double x);
long double fs_sqrtl(long double x);
long double fs_logl(long double x);
long double fs_expl(long double x);
long double fs_cosl(long double x);
long double fs_fmodl(long double x, long double y);

#endif

/* END fs_math.h */

This is the output from fslog_10 on my machine:

/* BEGIN fs_log10.c output */

fs_log10(10000) - 4 is 0.000000e+000
fs_pow(0.0001, -0.25) - 10 is 3.552714e-015
fs_cos(DEGREES_TO_RADIANS(-3540)) - 0.5 is 9.992007e-016
fs_sqrt(2) * fs_sqrt(2) - 2 is -4.440892e-016

log10(10000) - 4 is 0.000000e+000
pow(0.0001, -0.25) - 10 is 0.000000e+000
cos(DEGREES_TO_RADIANS(-3540)) - 0.5 is -1.060133e-015
sqrt(2) * sqrt(2) - 2 is 4.440892e-016

/* END fs_log10.c output */

--
pete

[pete]

pete wrote:

A Newton-Raphson square root algorithm,
can be terminated more logically:

double sq_rt(double x)
{
if (x 0) {
const double c = x;
double y = c / 2 + 0.5;

do {
x = y;
y = (c / x + x) / 2;
} while (x y);
}
return x;
}

The extra bit of analysis here is that for any positive N
and any positive Guess,
((N / Guess + Guess) / 2) is ***greater than or equal to***
the square root of N.
So, if the first Guess is greater than or equal
to the square root of N,
then each subsequent Guess will be lower,
until at some point the Guess will be low enough so that
((N / Guess + Guess) / 2) isn't less than Guess;
And when that happens,
then Guess is the greatest double value
that is less than or equal to the square root of N.
The choice for first guess being (N / 2 + 0.5), follows from this:
The square root of N, is somewhere between N and 1.0,
so the first two candidates for first guess are N and 1.0.

((N / N + N) / 2) and ((N / 1.0 + 1.0) / 2)
happen to both be equal to (N / 2 + 0.5),
and (N / 2 + 0.5) is greater than or equal
to the square root of any positive N,
making (N / 2 + 0.5) be a good value for first guess.

--
pete

[Ben Bacarisse]

"Malcolm McLean" <re*******@btinternet.comwrites:

The webpages for my new book are now up and running.

Did you compile and test the code? Is the code in the book the same
as that on the web pages? I am worried by a book that contains:

if(x & 0x7FFFFFFFF < y & 0x7FFFFFFF)

I'd have thought that all compilers would tell you about the
(probable) extra F and that the simplest testing would have shown up
the missing parentheses (I don't think you really meant what you
wrote).

--
Ben.

[Ben Bacarisse]

"Malcolm McLean" <re*******@btinternet.comwrites:

The webpages for my new book are now up and running.

Since there seem to be significant errors, I decided to have another
look. I do not want to be unkind, but I can't see how, as an
academic, you can publish a book you are clearly not qualified to
write. The smattering of typographical errors is unfortunate (and not
really forgivable since I'd have thought that most publishers will
take your actual compilable source code) but to claim that queue might
be implemented like this:

int queue[100];
int head;
int tail;

void add(int x)
{
if(tail == 100]
tail = 0;
queue[tail++] = x;
}

int remove(void)
{
int answer = queue[head];
head++;
if(head == 100)
head = 0;
return answer;
}

is absurd. I have improved the formatting but left in the silly
mistakes like ] closing the first 'if'.

I have been reticent in the past to post bad code from online lecture
notes because I am sympathetic to some of the pressures that teachers
are, at times, put under[1], but you are asking that people, who want
to learn, should pay over £16 for this kind of stuff. You chose to
write and publish it.

This is may be the biggest howler, but there are so many, I would hope
that you consider withdrawing it and correcting the worst of them
before put this before the public. I note that it is privately
published (by you) so this would not be a problem for you.

[1] "Last one in teaches the programming for accountants course. You
don't know C? -- well you've got a couple of days before the course
starts!"

--
Ben.

[mstorkamp]

On Jul 24, 3:18 pm, "Malcolm McLean" <[e-mail]:

The webpages for my new book are now up and running.

It may be I've actually leaned something new from the sample pages of
the book. To quote:

Note that strlen() is a "pure function". It performs no input or
output, and all the information it requires is contained in the
parameters. One of the features of C is that there is no distinction
between a "function", which calculates something, and a "procedure",
which performs IO.

Now I had always had in my mind (going back to the days of learning
BASIC in the '70s) that the difference between a function and
procedure is that a function returns a value and a procedure doesn't.
But I could be wrong.

[osmium]

<ms*******@yahoo.comwrote:

On Jul 24, 3:18 pm, "Malcolm McLean" <[e-mail]:

>The webpages for my new book are now up and running.

It may be I've actually leaned something new from the sample pages of
the book. To quote:

Note that strlen() is a "pure function". It performs no input or
output, and all the information it requires is contained in the
parameters. One of the features of C is that there is no distinction
between a "function", which calculates something, and a "procedure",
which performs IO.

Now I had always had in my mind (going back to the days of learning
BASIC in the '70s) that the difference between a function and
procedure is that a function returns a value and a procedure doesn't.
But I could be wrong.

I had been holding an open mind on the book.

But I now join the people who think the book is awful. There is no
justification for the statement you quote; at best, it is terribly clumsy.
A procedure has side effects, a function does not, one *possible* side
effect is I/O. There are tons of other side effects which do not involve
I/O.

Yes, a pure function returns a value with no side effects.

[Richard Tobin]

In article <11**********************@19g2000hsx.googlegroups. com>,
<ms*******@yahoo.comwrote:

>Now I had always had in my mind (going back to the days of learning
BASIC in the '70s) that the difference between a function and
procedure is that a function returns a value and a procedure doesn't.
But I could be wrong.

Basic used the term "subroutine" - hence GOSUB.

But the correct conclusion to draw is that there isn't a consistent
convention for the terms "function" and "procedure". Different
computer languages use them differently. Usually it's clear from
context what is meant. But even when someone uses the term "pure
function" you can't always be sure whether they mean

(a) has a result depending only on the inputs,
(b) has no side-effects, or
(c) both.

-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.

[Eric Sosman]

ms*******@yahoo.com wrote On 07/25/07 10:56,:

On Jul 24, 3:18 pm, "Malcolm McLean" <[e-mail]:

>>The webpages for my new book are now up and running.

It may be I've actually leaned something new from the sample pages of
the book. To quote:

Note that strlen() is a "pure function". It performs no input or
output, and all the information it requires is contained in the
parameters. One of the features of C is that there is no distinction
between a "function", which calculates something, and a "procedure",
which performs IO.

He says there's no distinction, tries to draw one,
and ends up spreading confusion.

Now I had always had in my mind (going back to the days of learning
BASIC in the '70s) that the difference between a function and
procedure is that a function returns a value and a procedure doesn't.
But I could be wrong.

Different programming languages use different terms
to describe various flavors of functions, subroutines,
procedures, methods, lambda expressions, and so on. When
you're dealing with definitional niceties, you need to do
so in the context of a particular language; the next in
line may use the same word but with a different meaning.

In the specific case of C, "procedure" is a word with
no meaning. The Standard does not define it; the Standard
does not even use the word. So there's no way for C to
clear up any confusion you may have about the precise meaning
of "procedure;" one might just as well ask about the precise
meaning of "coroutine."

By the way, "pure function" is another phrase not defined
or used by the C Standard. The term is in general use, with
a meaning somewhat along the lines Malcolm mentions: most
people describe a function as "pure" if it has no "visible"
side-effects. Section 7.5 paragraph 3 of the C Standard
explicitly permits strlen() to have an externally-visible
side-effect, so strlen() need not be "pure" at all!

--
Er*********@sun.com

[pete]

Malcolm McLean wrote:

>
The webpages for my new book are now up and running.

(Follow the links)

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

On page 21, it says "Normally we typedef structures."
Most of the regulars on this newsgroup usually don't.

--
pete

[regis]

pete wrote:

Malcolm McLean wrote:

>>The webpages for my new book are now up and running.
(Follow the links)
http://www.personal.leeds.ac.uk/~bgy1mm

On page 21, it says "Normally we typedef structures."
Most of the regulars on this newsgroup usually don't.

So what ? I do not see the point.
Most common libraries I find on my system typedef them:
- X11 Window system: (/usr/include/X11/Xlib.h)
- Gimp ToolKit library GTK and Glib: (/usr/include/gtk-2.0/*.h)
- Tcl-Tk C library (/usr/include/{tk,tcl}.h)
- Audio library ALSA: (/usr/include/alsa/*.h)
- Simple Direct Media Layer SDL: (/usr/include/SDL/*.h)
- Image manipulation library Image-Magick: (/usr/includemagick/*.h)
- Freetype truetype library: (/usr/include/freetype2/freetype/*.h)
- t1lib Postscript Type1 library: (/usr/include/t1lib.h)
- Ncurses Screen handling library: (/usr/include/ncurses/*.h)
- readline library: /usr/include/readline/*.h)
- Regular Expressions : (/usr/include/regex.h)
- linux headers: (/usr/include/linux/*.h)
- JPEG library jpeglib: (/usr/include/jpeglib.h)
- PNG library libpng: (/usr/include/libpng/png.h)
- zlib compression library: (/usr/include/zlib.h)
- my stdio.h implements FILE with a typedef'ed struct,
- its Posix counterpart for directories DIR as well, in dirent.h

unistd.h, inet sockets interface do not typedef struct...
GL do not typedef structs but typedef pointers to structs...

--
regis

[Keith Thompson]

Eric Sosman <Er*********@sun.comwrites:

ms*******@yahoo.com wrote On 07/25/07 10:56,:

[...]

>It may be I've actually leaned something new from the sample pages of
the book. To quote:

Note that strlen() is a "pure function". It performs no input or
output, and all the information it requires is contained in the
parameters. One of the features of C is that there is no distinction
between a "function", which calculates something, and a "procedure",
which performs IO.

He says there's no distinction, tries to draw one,
and ends up spreading confusion.

>Now I had always had in my mind (going back to the days of learning
BASIC in the '70s) that the difference between a function and
procedure is that a function returns a value and a procedure doesn't.
But I could be wrong.

Different programming languages use different terms
to describe various flavors of functions, subroutines,
procedures, methods, lambda expressions, and so on. When
you're dealing with definitional niceties, you need to do
so in the context of a particular language; the next in
line may use the same word but with a different meaning.

In the specific case of C, "procedure" is a word with
no meaning. The Standard does not define it; the Standard
does not even use the word. So there's no way for C to
clear up any confusion you may have about the precise meaning
of "procedure;" one might just as well ask about the precise
meaning of "coroutine."

By the way, "pure function" is another phrase not defined
or used by the C Standard. The term is in general use, with
a meaning somewhat along the lines Malcolm mentions: most
people describe a function as "pure" if it has no "visible"
side-effects. Section 7.5 paragraph 3 of the C Standard
explicitly permits strlen() to have an externally-visible
side-effect, so strlen() need not be "pure" at all!

I don't have too much of a problem with a C book defining and using
terms like "procedure" and "pure function", as long as it (a) defines
them clearly, (b) defines them in ways that don't conflict too badly
with common usage, and (c) make it very clear that the terms are being
defined by the book, not by the C standard.

It could also be argued that a C book should just use the terminology
defined by the standard, but Malcolm's book isn't really *about* C;
it's primarily about algorithms, using C to present them. In that
context, distinguishing "procedures" and "pure functions" from other
functions is probably sensible.

<OT>
An early draft version of Ada (from 1979) had "procedures" that
perform actions without returning a value, "value-returning
procedures" that perform actions and return a value, and "functions"
that return a value and are tightly restricted in their side effects.
For example, you couldn't add I/O statements to a function. In later
revisions, value-returning procedures were dropped, and the
restrictions on functions were loosened.
</OT>

But I've never heard of the term "procedure" being defined in terms of
I/O. Normally a "procedure" would be what C calls a function
returning void. A lot of C functions also have a primary purpose of
causing side effects, but return a result that indicates whether it
succeeded or not; some other languages might, for example, use a
procedure that raises an exception on failure. (qsort() is a good
example.)

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[regis]

Alan Curry wrote:

regis <re***@dil.univ-mrs.frwrote:

>pete wrote:

>>On page 21, it says "Normally we typedef structures."
Most of the regulars on this newsgroup usually don't.

So what ? I do not see the point.
Most common libraries I find on my system typedef them:
- X11 Window system: (/usr/include/X11/Xlib.h)

Which also gives us the lovely "typedef char *XPointer" as a generic pointer
type - I don't think Xlib is the place to look for examples of good style in
modern C.

I did not cite these libraries as places to look for
good style or modern C.
And whether typedef'ing structs, numeric types or pointers
is good or bad practice is not my point.
My point is: typedef'ing structs is a wide practice.

typedef'd pointers are even worse.

( here we agree... )

--
regis

[Ivar Rosquist]

On Tue, 24 Jul 2007 21:18:10 +0100, Malcolm McLean wrote:

The webpages for my new book are now up and running.

The book, Basic Algorithms, describes many of the fundamental algorithms
used in practical programming, with a bias towards graphics. It includes
mathematical routines from the basics up, including floating point
arithmetic, compression techniques, including the GIF and JPEG file
formats, hashing, red black trees, 3D and 3D graphics, colour spaces,
machine learning with neural networks, hidden Markov models, and fuzzy
logic, clustering, fast memory allocators, and expression parsing.

Congratulations! Your books provide a shiny, lucid example on how
books ought not to be written. Please keep up the good work.

[Richard Bos]

ms*******@yahoo.com wrote:

On Jul 24, 3:18 pm, "Malcolm McLean" <[e-mail]:

The webpages for my new book are now up and running.

It may be I've actually leaned something new from the sample pages of
the book. To quote:

Note that strlen() is a "pure function". It performs no input or
output, and all the information it requires is contained in the
parameters. One of the features of C is that there is no distinction
between a "function", which calculates something, and a "procedure",
which performs IO.

Well, that goes to show that whoever originally wrote that has no idea
what he's talking about. What is called a "function" and what a
"procedure" varies wildly - for example, in Pascal, a function returns a
value, a procedure does not, and that is _all_ the difference - and
separating function/procedure/routines into "things that calculate
something" and "things that perform IO", with nothing in between and no
provision for "things that calculate something _and_ perform IO" is
short-sighted as well as less than useful.

Now I had always had in my mind (going back to the days of learning
BASIC in the '70s) that the difference between a function and
procedure is that a function returns a value and a procedure doesn't.

That's Pascal. BASIC originally had only subroutines, no functions _or_
procedures. C has only functions, which may or may not return a value
and may or may not perform calculation and/or IO.

Richard

[Mark Bluemel]

Malcolm McLean wrote:

The webpages for my new book are now up and running.

Given the amount of criticism raised so far, would you comment on how
the book was edited and reviewed/

[Christopher Benson-Manica]

regis <re**************@free.frwrote:

I did not cite these libraries as places to look for
good style or modern C.

My point is: typedef'ing structs is a wide practice.

If the practice is both widespread and stylistically questionable
(which you seem to be agreeing with), the statement in the book would
have been better phrased "It is common practice to typedef structs,
but it is not considered good style."

--
C. Benson Manica | I appreciate all corrections, polite or otherwise.
---------------------------------------------------------------------------
"If it moves, it's design. If it blows up, it's hardware. If it doesn't
work, it's software." - Anonymous

[Richard Heathfield]

Christopher Benson-Manica said:

regis <re**************@free.frwrote:

>I did not cite these libraries as places to look for
good style or modern C.

>My point is: typedef'ing structs is a wide practice.

If the practice is both widespread and stylistically questionable
(which you seem to be agreeing with), the statement in the book would
have been better phrased "It is common practice to typedef structs,
but it is not considered good style."

....except, of course, by those who consider it good style (myself
included).

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[regis]

Christopher Benson-Manica wrote:

regis <re**************@free.frwrote:

>>I did not cite these libraries as places to look for
good style or modern C.

>>My point is: typedef'ing structs is a wide practice.

If the practice is both widespread and stylistically questionable
(which you seem to be agreeing with),

( No. I agreed that the typedef'ing of pointers to structs
was not a good idea. I personally always typedef structs with
the same name as the tag, the way it is done automatically in C++.)

the statement in the book would
have been better phrased "It is common practice to typedef structs,
but it is not considered good style."

( it's more a matter of nice/ugly than good/bad practice.
The latter vocable generally leads to unnecessary religious wars... )

[Christopher Benson-Manica]

regis <re***@dil.univ-mrs.frwrote:

( No. I agreed that the typedef'ing of pointers to structs
was not a good idea. I personally always typedef structs with
the same name as the tag, the way it is done automatically in C++.)

To each his own, but I'm not sure the C++ comparison is particularly
useful. <ot>A C++ struct is quite a different animal than a C
one.</ot>

( it's more a matter of nice/ugly than good/bad practice.
The latter vocable generally leads to unnecessary religious wars... )

As much fun as burning heretics at the stake can be, you and Richard
are probably right.

--
C. Benson Manica | I appreciate all corrections, polite or otherwise.
cbmanica(at)gmail.com |
----------------------| I do not currently read any posts posted through
sdf.lonestar.org | Google groups, due to rampant unchecked spam.

[REH]

On Jul 26, 4:05 pm, Christopher Benson-Manica
<[e-mail]:

To each his own, but I'm not sure the C++ comparison is particularly
useful. <ot>A C++ struct is quite a different animal than a C
one.</ot>

Actually, if you define a struct in C++ the same as you do in C, it is
guaranteed to be equivalent to the C version.

[Malcolm McLean]

"Ivar Rosquist" <IR*******@irq.orgwrote in message
news:pa*********************@irq.org...

Congratulations! Your books provide a shiny, lucid example on how
books ought not to be written. Please keep up the good work.

What a nasty little man you are. Everyone else has contributed something
positive, even it is only spotting a typo, but you just have spiteful things
to say.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

[Richard Heathfield]

Malcolm McLean said:

>
"Ivar Rosquist" <IR*******@irq.orgwrote in message
news:pa*********************@irq.org...

>Congratulations! Your books provide a shiny, lucid example on how
books ought not to be written. Please keep up the good work.

What a nasty little man you are. Everyone else has contributed
something positive, even it is only spotting a typo, but you just have
spiteful things to say.

Malcolm, if that is the worst crit you ever get, count yourself
thrice-blessed. Critcritters can get a lot nastier than that.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Christopher Benson-Manica]

Malcolm McLean <re*******@btinternet.comwrote:

What a nasty little man you are. Everyone else has contributed something
positive, even it is only spotting a typo, but you just have spiteful things
to say.

I do hope you will take the time to acknowledge those positive
contributions.

--
C. Benson Manica | I appreciate all corrections, polite or otherwise.
cbmanica(at)gmail.com |
----------------------| I do not currently read any posts posted through
sdf.lonestar.org | Google groups, due to rampant unchecked spam.

[Malcolm McLean]

"Keith Thompson" <ks***@mib.orgwrote in message
news:ln************@nuthaus.mib.org...

I don't have too much of a problem with a C book defining and using
terms like "procedure" and "pure function", as long as it (a) defines
them clearly, (b) defines them in ways that don't conflict too badly
with common usage, and (c) make it very clear that the terms are being
defined by the book, not by the C standard.

It could also be argued that a C book should just use the terminology
defined by the standard, but Malcolm's book isn't really *about* C;
it's primarily about algorithms, using C to present them. In that
context, distinguishing "procedures" and "pure functions" from other
functions is probably sensible.

The question is whether to use an existing word or coin a new one.

For my purposes

int foo(void)

and

void foo(int *ret)

don't have any really important differences. From a compiler writer's point
of view, of course, it is important that if(foo()) is legal whilst
if(foo(&x)) is not.
Similalry from an algorithms point of view we are not too interested in
whether a function receives its parameters as arguements or in globals.
Under the bonnet a lot of compilers implement globals with a pointer that is
in scope for every function, anyway.

So the important difference is between code which calculates something, and
code which does something. You could stretch the point by saying that flow
control is a third class of code, but that can probably be ignored.

"Function" is the accepted mathematical term for a mapping of input to
output, which is what a calculation is, so I can use it. "Procedure" isn't
firmed up, largely because the word is used in so many different ways.
However it has the English meaning of a "series of actions". Given that I'd
decided not to coin my own words, procedure seems the best choice for a
subroutine that isn't only a function. Procedures can call functions, but
functions cannot call procedures.

>
But I've never heard of the term "procedure" being defined in terms of
I/O. Normally a "procedure" would be what C calls a function
returning void. A lot of C functions also have a primary purpose of
causing side effects, but return a result that indicates whether it
succeeded or not; some other languages might, for example, use a
procedure that raises an exception on failure. (qsort() is a good
example.)

That's my use. An "action" is IO, if you think about it. Everything else is
just shuffling bits about in memory.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

[Malcolm McLean]

"Mark Bluemel" <ma**********@pobox.comwrote in message
news:f8**********@aioe.org...

Malcolm McLean wrote:

>The webpages for my new book are now up and running.

Given the amount of criticism raised so far, would you comment on how the
book was edited and reviewed.

Most posters have been negative, but mainly it's been trivia - a few typing
errors, one actual buggy line. They somethimes invest huge significance in
this - "why write a book for which you are not qualified". In fact it would
be a miracle if not a single error crept into a 600 page book.

The brave new world of the internet disintermediates. That's why the book
costs sixteen pounds instead of the thirty to fifty you'd pay for the same
thing in a bookshop. The loss of a professional editor - it was done by me
and the artist, who is a non-programmer - is a double-edged sword. It means
you have more immediate contact with the the mind of the author, but it also
means that somethings that maybe should have been blue pencilled stay in.
It's too early in the internet publishing game to say how it will pan out.

The other factor, as someone else mentioned, is that I can make changes
quite easily. Unfortunately the tools are not quite there yet. For instance
the web pages were saved by Open Office, and it didn't make a very good job
of formatting the code. If I reformatted it all by hands inevitably you get
more typos. Then each change would ahve to be synchronised with two
versions. However I might go down that route, since the webpages are the
place most potential purchasers will probably land on first.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

[regis]

Malcolm McLean wrote:

>
"Mark Bluemel" <ma**********@pobox.comwrote in message
news:f8**********@aioe.org...

>Malcolm McLean wrote:

>>The webpages for my new book are now up and running.

Given the amount of criticism raised so far, would you comment on how
the book was edited and reviewed.

Most posters have been negative, but mainly it's been trivia - a few
typing errors, one actual buggy line. They somethimes invest huge
significance in this - "why write a book for which you are not
qualified". In fact it would be a miracle if not a single error crept
into a 600 page book.

There is one error that is neither typographic or programmatic.
it's a marketting one: In no bookstore you will see
"Basic Algorithms" on the same shelf as
"12 common atheist arguments (refuted)"...

--
regis

[Keith Thompson]

"Malcolm McLean" <re*******@btinternet.comwrites:
[...]

"Function" is the accepted mathematical term for a mapping of input to
output, which is what a calculation is, so I can use it. "Procedure"
isn't firmed up, largely because the word is used in so many different
ways. However it has the English meaning of a "series of
actions". Given that I'd decided not to coin my own words, procedure
seems the best choice for a subroutine that isn't only a
function. Procedures can call functions, but functions cannot call
procedures.

[...]

Not coining your own word is fine. Coining your own meaning for an
existing word, IMHO, only causes confusion.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Keith Thompson]

"Malcolm McLean" <re*******@btinternet.comwrites:
[...]

The other factor, as someone else mentioned, is that I can make changes
quite easily. Unfortunately the tools are not quite there yet. For instance
the web pages were saved by Open Office, and it didn't make a very good job
of formatting the code. If I reformatted it all by hands inevitably you get
more typos. Then each change would ahve to be synchronised with two
versions. However I might go down that route, since the webpages are the
place most potential purchasers will probably land on first.

If I were going to write a book on C, I'd maintain all the C sources
separately, and import them into whatever word processing program I'd
use, so the question wouldn't arise. And I'd never include a code
sample in a published work unless I had actually compiled and executed
it. Logical errors happen, as do typos in English text, and they're
difficult to avoid. Most typos in actual code can be avoided.

If you're stuck with exporting your C source code from Open Office,
run it through "indent" or some similar tool rather than trying to
reformat it by hand.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Eric Sosman]

Malcolm McLean wrote:

>
"Keith Thompson" <ks***@mib.orgwrote in message
news:ln************@nuthaus.mib.org...

>I don't have too much of a problem with a C book defining and using
terms like "procedure" and "pure function", as long as it (a) defines
them clearly, (b) defines them in ways that don't conflict too badly
with common usage, and (c) make it very clear that the terms are being
defined by the book, not by the C standard.

It could also be argued that a C book should just use the terminology
defined by the standard, but Malcolm's book isn't really *about* C;
it's primarily about algorithms, using C to present them. In that
context, distinguishing "procedures" and "pure functions" from other
functions is probably sensible.

The question is whether to use an existing word or coin a new one.

... or whether not to bother at all, since the distinction
between "method" and "section" is meaningless in C.

For my purposes

int foo(void)

and

void foo(int *ret)

don't have any really important differences. From a compiler writer's
point of view, of course, it is important that if(foo()) is legal whilst
if(foo(&x)) is not.

Not a special case, nor an essential difference between a
void-valued function and an other-valued one. For example,
consider that

struct bar baz(void);
if (baz()) ...

.... is also invalid, even though baz returns a value. It is
not the void-ness or void-not of a function that determines
whether its returned value can be used in an `if' (or assigned
to a variable, or whatever), but the type of the returned value.
A void-valued function is illegal in some contexts; a struct-
valued function is illegal in some contexts; an int-valued
function is illegal in some contexts. It's the type that makes
the difference, not the void-ness.

Similalry from an algorithms point of view we are not too interested in
whether a function receives its parameters as arguements or in globals.
Under the bonnet a lot of compilers implement globals with a pointer
that is in scope for every function, anyway.

I've never encountered one that does so, no, not even once --
but I've encountered somewhat fewer than all compilers. No doubt
you're right, and the world is full of "a lot" of weird compilers.
(It would go some way towards explaining your ideas about C.)

So the important difference is between code which calculates something,
and code which does something. You could stretch the point by saying
that flow control is a third class of code, but that can probably be
ignored.

Why is this difference "important?" Why is it even "the least
bit important?" It's a pointless digression in the book, that's
all. You should consider removing it from the second printing.

"Function" is the accepted mathematical term for a mapping of input to
output, which is what a calculation is, so I can use it. "Procedure"
isn't firmed up, largely because the word is used in so many different
ways. However it has the English meaning of a "series of actions". Given
that I'd decided not to coin my own words, procedure seems the best
choice for a subroutine that isn't only a function. Procedures can call
functions, but functions cannot call procedures.

Since "procedure isn't firmed up," you can say whatever you
like about it without advancing the discussion.

(Your text offers strlen() as an example of a "function," but
by your definition it isn't one, or at any rate needn't be one.)

>But I've never heard of the term "procedure" being defined in terms of
I/O. Normally a "procedure" would be what C calls a function
returning void. A lot of C functions also have a primary purpose of
causing side effects, but return a result that indicates whether it
succeeded or not; some other languages might, for example, use a
procedure that raises an exception on failure. (qsort() is a good
example.)

That's my use. An "action" is IO, if you think about it. Everything else
is just shuffling bits about in memory.

http://en.wikipedia.org/wiki/Begging_the_question

--
Eric Sosman
es*****@ieee-dot-org.invalid

[Eric Sosman]

Christopher Benson-Manica wrote:

regis <re**************@free.frwrote:

>I did not cite these libraries as places to look for
good style or modern C.

>My point is: typedef'ing structs is a wide practice.

If the practice is both widespread and stylistically questionable
(which you seem to be agreeing with), the statement in the book would
have been better phrased "It is common practice to typedef structs,
but it is not considered good style."

Who died and made you Pope? ;-)

Personally, I typedef structs and unions, don't typedef data
pointers, and sometimes typedef function pointers. I'm not
promoting my style as a model for others to follow: make up your
own mind. But neither am I apologizing for it: who died and made
you Pope? Nor am I condemning people whose styles are different:
who died and made *me* Pope?

Consider for a moment that a professional programmer spends
far more time reading code written by other people than writing
original code of his own. (That is, after all, the fundamental
promise of "code re-use.") It follows that if you are convinced
you know the One Right Way to do things, your programming career
will be short and inglorious.

--
Eric Sosman
es*****@ieee-dot-org.invalid

[Charlton Wilbur]

>>>>"CBM" == Christopher Benson-Manica <at***@otaku.freeshell.orgwrites:

CBMI do hope you will take the time to acknowledge those
CBMpositive contributions.

And either fix the errors at once or withdraw the book until they can
be fixed. There's no excuse for spreading incorrect information.

Charlton
--
Charlton Wilbur
cw*****@chromatico.net

[pete]

Keith Thompson wrote:

But I've never heard of the term "procedure" being defined in terms of
I/O. Normally a "procedure" would be what C calls a function
returning void. A lot of C functions also have a primary purpose of
causing side effects, but return a result that indicates whether it
succeeded or not; some other languages might, for example, use a
procedure that raises an exception on failure. (qsort() is a good
example.)

qsort is a good example of what?

--
pete

[pete]

Malcolm McLean wrote:

But I've never heard of the term "procedure"
being defined in terms of I/O.
Normally a "procedure" would be what C calls a function
returning void. A lot of C functions also have a primary purpose of
causing side effects, but return a result that indicates whether it
succeeded or not; some other languages might, for example, use a
procedure that raises an exception on failure. (qsort() is a good
example.)

That's my use. An "action" is IO, if you think about it.
Everything else is
just shuffling bits about in memory.

I don't understand what you mean by either IO or "action".

All that qsort does, is to shuffle bits about in memory.

--
pete

[Keith Thompson]

pete <pf*****@mindspring.comwrites:

Keith Thompson wrote:

>But I've never heard of the term "procedure" being defined in terms of
I/O. Normally a "procedure" would be what C calls a function
returning void. A lot of C functions also have a primary purpose of
causing side effects, but return a result that indicates whether it
succeeded or not; some other languages might, for example, use a
procedure that raises an exception on failure. (qsort() is a good
example.)

qsort is a good example of what?

Of me not paying sufficient attention before posting. (I had assumed
qsort returns a status result; in fact, it returns void. Any failure,
such as an inconsistent comparison function, invokes undefined
behavior.)

system() is a better example of what I was talking about.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Christopher Benson-Manica]

Eric Sosman <es*****@ieee-dot-org.invalidwrote:

Christopher Benson-Manica wrote:

If the practice is both widespread and stylistically questionable
(which you seem to be agreeing with), the statement in the book would
have been better phrased "It is common practice to typedef structs,
but it is not considered good style."

Who died and made you Pope? ;-)

Clearly my *post* could have been better phrased; fortunately the text
will not be included in any book :-)

(I'm glad it's Friday.)

--
C. Benson Manica | I appreciate all corrections, polite or otherwise.
cbmanica(at)gmail.com |
----------------------| I do not currently read any posts posted through
sdf.lonestar.org | Google groups, due to rampant unchecked spam.

[Christopher Benson-Manica]

Keith Thompson <ks***@mib.orgwrote:

Not coining your own word is fine. Coining your own meaning for an
existing word, IMHO, only causes confusion.

Perhaps Malcolm would consider including the glossary in the free
preview for the benefit of future (p)reviewers?

--
C. Benson Manica | I appreciate all corrections, polite or otherwise.
cbmanica(at)gmail.com |
----------------------| I do not currently read any posts posted through
sdf.lonestar.org | Google groups, due to rampant unchecked spam.

[Spoon]

Eric Sosman wrote:

Who died and made you Pope? ;-)

AFAIU, there can be only one pope.

Therefore, the answer to your question must be "the Pope".

[Richard Heathfield]

Charlton Wilbur said:

>>>>>"CBM" == Christopher Benson-Manica <at***@otaku.freeshell.org>
>writes:

CBMI do hope you will take the time to acknowledge those
CBMpositive contributions.

And either fix the errors at once or withdraw the book until they can
be fixed. There's no excuse for spreading incorrect information.

Electronically, you're right (although of course there can be reasons).
Paper copies are rather harder to recall and extraordinarily costly to
correct.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Ivar Rosquist]

On Thu, 26 Jul 2007 21:46:22 +0100, Malcolm McLean wrote:

"Ivar Rosquist" <IR*******@irq.orgwrote in message
news:pa*********************@irq.org...

>Congratulations! Your books provide a shiny, lucid example on how books
ought not to be written. Please keep up the good work.

What a nasty little man you are. Everyone else has contributed something
positive, even it is only spotting a typo, but you just have spiteful
things to say.

Oh, I'm sorry if I hurt your feelings. Here, have this lollipop
and be happy again.

[Charlton Wilbur]

>>>>"MMcL" == Malcolm McLean <re*******@btinternet.comwrites:

MMcL"Ivar Rosquist" <IR*******@irq.orgwrote in message
MMcLnews:pa*********************@irq.org...

>Congratulations! Your books provide a shiny, lucid example on
how books ought not to be written. Please keep up the good
work.

MMcLWhat a nasty little man you are. Everyone else has
MMcLcontributed something positive, even it is only spotting a
MMcLtypo, but you just have spiteful things to say.

You know, this is a technical newsgroup, and you have written a
technical book. If you can't handle having your errors pointed out,
then this is not the place for you.

If you want nothing but an effusion of praise, I recommend finding a
self-esteem building therapy group, and may you find much value in it.

Charlton


--
Charlton Wilbur
cw*****@chromatico.net

[Richard]

Charlton Wilbur <cw*****@chromatico.netwrites:

If you want nothing but an effusion of praise, I recommend finding a
self-esteem building therapy group, and may you find much value in it.

Charlton

The following is pointing out errors? :-

Congratulations! Your books provide a shiny, lucid example on how
books ought not to be written. Please keep up the good work.

You need your sensors adjusting.

[Ben Bacarisse]

"Malcolm McLean" <re*******@btinternet.comwrites:

"Mark Bluemel" <ma**********@pobox.comwrote in message
news:f8**********@aioe.org...

>Malcolm McLean wrote:

>>The webpages for my new book are now up and running.

Given the amount of criticism raised so far, would you comment on
how the book was edited and reviewed.

Most posters have been negative, but mainly it's been trivia - a few
typing errors, one actual buggy line. They somethimes invest huge
significance in this - "why write a book for which you are not
qualified". In fact it would be a miracle if not a single error crept
into a 600 page book.

I feel that is directed at me (since I write that rather harsh remark)
and I feel I should justify it. It most certainly was *not* based
simply on the large number of typos and syntax errors in the code in
the early pages of the book, but on what you were saying about
algorithms.

Do you think that the code you give is a useful implementation of a
queue? Does it deal with the only slightly tricky part of
implementing a circular buffer as a C array (distinguishing between a
full and an empty queue)? Do you think someone learning about basic
algorithms would be anything but baffled by this code to remove a list
item:

void removebaddy(ROOM *room, char *name)
{
BADDY *ptr = room->baddies;
BADDY *prev = 0;

while(ptr)
{
if(!strcmp(name, ptr->name))
{
if(ptr == room->baddies)
room->baddies = ptr;
else
{
prev->next = ptr->next;
continue;
}
prev = ptr;
ptr = ptr->next;
}
}
}

[Having tidied up the code from the website, I now see that this
*could* be called a typo, but it is still perplexing for a beginner --
especially as it is immediately preceded by another loop with its own
typo -- looping while (*ptr) ... to iterate down a linked list].

Your hash table can fill up (I don't see that even commented on, but I
may have missed it) and the add function will then just loop forever.
If the table is full, both the lookup and delete functions will loop
indefinitely. If a student wrote that, they'd get quite a bit if
credit for a reasonable attempt, but if they asked if I thought they
were now qualified to write a book on algorithms, I'd have to say no.

Maybe you know how to do all this properly. If that is the case, then
of course you are qualified to write this book, but then I must ask
why did you not properly implement a queue, or prevent your hash table
functions form failing mysteriously in some cases? It can't have been
to keep the code simple for teaching. I don't see any teaching value
in leaving your queue functions so sparse they don't work at all. And
a simple test to fail if the last hash table entry is about to used
would make the example better for students (though it would have to go
for any serious practical use).

I have other objections, but they are entirely off topic here (because
they are not manifest in you C code). If you had posted in
comp.programming I'd have felt more free to comment.

--
Ben.

[Eric Sosman]

Malcolm McLean wrote On 07/26/07 17:19,:

"Mark Bluemel" <ma**********@pobox.comwrote in message
news:f8**********@aioe.org...

>>Malcolm McLean wrote:

>>>The webpages for my new book are now up and running.

Given the amount of criticism raised so far, would you comment on how the
book was edited and reviewed.

Most posters have been negative, but mainly it's been trivia - a few typing
errors, one actual buggy line. They somethimes invest huge significance in
this - "why write a book for which you are not qualified". In fact it would
be a miracle if not a single error crept into a 600 page book.

That would, indeed, be miraculous. On the other hand,
the "run rate" of three obvious errors in one eleven-line
function suggests that we may be about to witness a different
miracle: a book thinner than its own errata.

--
Er*********@sun.com

[Malcolm McLean]

"Keith Thompson" <ks***@mib.orgwrote in message
news:ln************@nuthaus.mib.org...

If I were going to write a book on C, I'd maintain all the C sources
separately, and import them into whatever word processing program
I'd use, so the question wouldn't arise. And I'd never include a code
sample in a published work unless I had actually compiled and
executed it. Logical errors happen, as do typos in English text, and
they're difficult to avoid. Most typos in actual code can be avoided.

If you're stuck with exporting your C source code from Open Office,
run it through "indent" or some similar tool rather than trying to
reformat it by hand.

That's basically what's been done. The source is in files, which have been
compiled on UNIX and Windows, and cut and pasted into Open Office.
The problem is that I don't have a tool that will automatically format code,
certainly not lay it out on the page. In fact there isn't a decent
fixed-pitch font suitable for printing code, the ones that are in common use
are too wide and all the lines wrap.
So in practise the code has to be touched by human hands. You see the
problem on the web pages - these are dumped from the Open Office export as
html option, and it doesn't make a good job of the code sections, though
they look OK in export as PDF.
Bascially the technology now exists to go directly from your desktop to
printed copy, but there are still lots of glitches. The artist has a
different version of the wordprocessor installed. Then for some reason his
Latha font stopped working. Then The printer refused to accept Open offcie
files, so I had to move to MS Word. Then the file needed to be uploaded over
ten times before it would convert - it turned out that one problem was that
I needed a short filename or it simply regarded the old versiona s the
current one. This is computers all over.
Much as I would like, it is not yet possible to press a button and have an
edit in place, though eventually we'll get there.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

[pete]

Malcolm McLean wrote:

if(ptr == room->baddies)
room->baddies = ptr;

Why is room->baddies being assigned a value
that it is already has?

--
pete

[Malcolm McLean]

"pete" <pf*****@mindspring.comwrote in message
news:46***********@mindspring.com...

Malcolm McLean wrote:

if(ptr == room->baddies)
room->baddies = ptr;

Why is room->baddies being assigned a value
that it is already has?

Those linked list routines are terribly buggy.
I think that section might need a rewrite.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm