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

[Malcolm McLean]

"Eric Sosman" <Er*********@su n.comwrote in message
news:1186440511 .431078@news1nw k...

Malcolm McLean wrote On 08/06/07 15:55,:
The book begins with a non-conforming implementation of
strlen(). It's kind enough to point out the nonconformity,
and goes on to provide a conforming replacement -- but one
wonders what purpose the bogus version serves, other than
to add thickness to the book.

The non-conforming implementation is an example of the book's style. It is
not written in C that happens to conform to the standards of the day, but in
C which I expect to still compile and work in a hundred years' time.

The book's implementation of mystrdup() compels a C99
compiler to emit diagnostics.

You repeat this several times. What you mean is that the function bodies are
given without headers. As you delve into deeper chapters you will soon see
why this is - text interspersed with code means that the headers make too
much visual mess without adding enough information content to justify
inclusion.
The problem is that by saying "a C99 compiler is compelled to emit
diagnostics" rather than "I think it would have been better to include
headers and prototypes" you really disqualify yourself as an objective
commentator.

At about this point, the text draws attention to some
coding conventions. Among them: the use of the identifier
`answer' to hold a function's return value. Oddly enough,
this mention is the last appearance of "answer" in the
chapter; the rest of the functions do not follow the
stated convention.

The convention applies for the whole book. "answer" isn't absolutely
uniform, but it is my normal choice for a variable to hold a return value.

>
There follows a peculiarity: A day-of-the-week function
that the author confesses he does not understand. The code
was "lifted from the net," says the book, but does not say
whether it was lifted from a reliable or from an unreliable
source. The text says it's all right to use a function you
don't understand, provided you "trust the author" -- but
since the author is unnamed, we do not have the means to
tell whether he is trustworthy.

Exactly. If you are doing very advanced programming then either you have to
be brillinat and encyclopedic, or you have to use code you don't understand.
Not an ideal situation, but it is very often necessary to do that.

>
The book next offers two macros (mentioning two more,
but not implementing them). The most obvious thing about
the book's macros is that their names consist entirely of
lower-case letters. While this is legal in C, it is far
more usual to name macros in upper-case -- some coding
standards, in fact, insist on this. The macros the book
offers aren't wrong, exactly, just in poor taste.

They are function-like macros. Unfortunately some of the arguments are
evaluated twice - a sng with the C macro system. I find lower case more
tasteful than upper

x = clamp(x, 0, 255);

is far easier on the eye than

x = CLAMP(x, 0, 255);

The upper case gives the macro an emphasis it shouldn't have.

>
The chapter closes with an argument that putting code
in libraries that can be shared by many programs is a Bad
Thing; the "right" way to re-use code is to paste a copy
wherever you happen to need one. (No, I am not making this
up!) And just for laughs, the chapter ends with an English
error.

Cut and paste is generally a far superior method. Libraries are fine if you
are implemeting something fundamental like OpenGL, but not when you need a
list of dependencies in your code. No one wants to link in five libraries
all with conflicting definition of "bool" just to use a few string
functions.

>
Statistical summary of "Some Simple Functions:"

- Number of function implementations shown: ten

- Number of functions that require compile-time
diagnostics: five

- Number of functions with bugs (beyond required
diagnostics) spotted by this reader: four

Need to check those bugs.

>
- Number of functions with bugs known to the author
(but published anyhow): one

- Number of macro implementations shown: two

- Number of bad macro implementations shown: two

- Influence of this more extensive reading on the
reader's opinion of the book: negative

Thanks for the input.

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

[Al Balmer]

On Mon, 06 Aug 2007 18:48:30 -0400, Eric Sosman <Er*********@su n.com>
wrote:

There follows an explanation of a procedure for finding
the date of Easter, credited to Gauss. This reader had not
heard of Gauss having worked on the problem, and finds it
hard to imagine that it would have interested Gauss: after
all, the best Gauss could hope to do with a formula already
in use would be to simplify it.

<OTOr develop a different formula. The Gaussian algorithm for
determining the date of Easter is actually quite well known. The story
is that he developed it in the course of determining his own birth
date, described by his mother as a Wednesday, eight days before
Ascension Day, which is forty days after Easter Sunday. </OT>

--
Al Balmer
Sun City, AZ

[pete]

Malcolm McLean wrote:

They are function-like macros. Unfortunately some of the arguments are
evaluated twice -

x = CLAMP(x, 0, 255);

The upper case gives the macro an emphasis it shouldn't have.

The upper case gives the macro an emphasis it *should* have,
*because* some of the arguments are evaluated twice.

--
pete

[Ian Collins]

Malcolm McLean wrote:

>>

Exactly. If you are doing very advanced programming then either you have
to be brillinat and encyclopedic, or you have to use code you don't
understand. Not an ideal situation, but it is very often necessary to do
that.

>>

You may not understand it, but you should cite the source and explain
why you trust it.

>>

They are function-like macros. Unfortunately some of the arguments are
evaluated twice - a sng with the C macro system. I find lower case more
tasteful than upper

x = clamp(x, 0, 255);

is far easier on the eye than

x = CLAMP(x, 0, 255);

The upper case gives the macro an emphasis it shouldn't have.

The point of the emphasis is to make it clear that they are macros.
Conventions evolve for good reasons and upper case macros the the
closest a C convention comes to being a standard.

Cut and paste is generally a far superior method. Libraries are fine if
you are implemeting something fundamental like OpenGL, but not when you
need a list of dependencies in your code. No one wants to link in five
libraries all with conflicting definition of "bool" just to use a few
string functions.

What utter bollocks. Do you cut and past your system's code for printf
into every module of code that uses it? No, you use the library.

What do you do when you find a bug in your copy and paste (which from
Eric's report appears to be common)?

--
Ian Collins.

[Ben Bacarisse]

"Malcolm McLean" <re*******@btin ternet.comwrite s:

I am not wedded
to the idea that my choice on size_t is the right one.
However there are some thigns you fail to appreciate.

<snip>

Another thing you fail to appreciate is that compressed data is
inherently a binary format, and ought to be a portable binary
format. So the size integer has to be stored as a fixed number of
bytes, with fixed endianness. So a size_t, with size unknown, isn't an
appropriate type. It makes a promise that might not be fulfilled.

So your function declares the 'len' parameter as 'int' rather than
'size_t'. How is that better? The size of 'int' is as "unknown" as
the size of 'size_t'.

A function that compresses data held in a C object (as yours does)
can't reply on being told the size in an int. That is what size_t is
for. Furthermore, writing out the size in a portable format is just
as easy if 'len' is a size_t as it is if 'len' is an int (slightly
easier, in fact, since you don't have to worry about >on negative
values).

If
you are determined to pass in a size_t nevertheless there are of
course ways round this, like storing the number of bits before the
size,

No, just write out the data length in the format of your choice. It
is, as I say, no easier when the length is in an int.

--
Ben.

[Eric Sosman]

Malcolm McLean wrote:

>
"Eric Sosman" <Er*********@su n.comwrote in message
news:1186440511 .431078@news1nw k...

>[...]
The book's implementation of mystrdup() compels a C99
compiler to emit diagnostics.

You repeat this several times. What you mean is that the function bodies
are given without headers. As you delve into deeper chapters

"Deeper." Good word, that. Suggests "down," and "lower,"
and "stuff rising over the tops of the waders." I'll pass,
thanks, and leave the journey to bolder spelunkers.

you will
soon see why this is - text interspersed with code means that the
headers make too much visual mess without adding enough information
content to justify inclusion.

How can you plead against "visual mess" when you cannot
even indent your code reasonably? How can you plead against
one or two #include lines in the face of those bloviated comments?
I don't buy it: I think the headers are missing because you are
careless, a sloppy worker.

The problem is that by saying "a C99 compiler is compelled to emit
diagnostics" rather than "I think it would have been better to include
headers and prototypes" you really disqualify yourself as an objective
commentator.

Diagnostics are also required from C89 compilers. There was
nothing to "require" such diagnostics from pre-Standard compilers,
but all those I used would have diagnosed at least two of your
functions. The fact that you didn't *know* the code was in error
for all C standards present and past and even for pre-Standard C
is a strong indication that you ought never to have written the book.
Ah, but that's the catch: You don't know, so you don't know you
don't know, don't you?

> At about this point, the text draws attention to some
coding conventions. Among them: the use of the identifier
`answer' to hold a function's return value. Oddly enough,
this mention is the last appearance of "answer" in the
chapter; the rest of the functions do not follow the
stated convention.

The convention applies for the whole book. "answer" isn't absolutely
uniform, but it is my normal choice for a variable to hold a return value.

A "normal choice" the chapter never uses again. But it's
a small point; you've shown more than once that you are no
respecter of convention, so it's no real surprise that you do
not even respect your own.

>There follows a peculiarity: A day-of-the-week function
that the author confesses he does not understand. The code
was "lifted from the net," says the book, but does not say
whether it was lifted from a reliable or from an unreliable
source. The text says it's all right to use a function you
don't understand, provided you "trust the author" -- but
since the author is unnamed, we do not have the means to
tell whether he is trustworthy.

Exactly. If you are doing very advanced programming then either you have
to be brillinat and encyclopedic, or you have to use code you don't
understand. Not an ideal situation, but it is very often necessary to do
that.

"Very advanced" programming??? Zeller's Congruence is the
sort of thing kids do in their first few weeks of BASIC. It's
often found in beginners' programming texts as a simple exercise
in integer division and modulus.

But: Why should we "trust the author" of this code "lifted
from the net" without attribution? There's lots and lots and
lots of code on the net, along with unmaskings of the faked Lunar
landings, squarings of the circle, proofs that the Universe is
only six thousand years old, and intriguing offers from Nigeria.
Why should we "trust the (unidentified) author" of this snippet?
Why do *you* trust him or her? Did you test the code? Perhaps
you did -- about as rigorously as you tested readline() ...

When you use the Argument From Authority, it is essential
to identify the Authority.

>[...]
- Number of functions with bugs (beyond required
diagnostics) spotted by this reader: four

Need to check those bugs.

You do, indeed. Or rather, "you did" -- but you didn't.
I could be wrong, but I truly think you were (are) capable
of checking, and of understanding what's wrong, and of fixing
it -- but you just didn't bother. Don't you *care* about the
quality of that which bears your name?

Thanks for the input.

Would it had not been necessary!

I bear no special animus towards you, Malcolm. I find you
irritating, but I imagine you find me much the same. This vile
book of yours, though -- It seems an affront, a flesh-crawlingly
repugnant scam perpetrated on unsuspecting buyers. The notion
that someone might actually give you money for this disaster is
close to sickening. I do not usually find myself emotionally
stirred by the goings-on in c.l.c., but you've both stirred
me and shaken me.

I'll say this for you: You are a brave person. Lots of
other people have written putrid books, but you are the first
I've known to invite your punishment.

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

[Richard]

"Malcolm McLean" <re*******@btin ternet.comwrite s:

They are function-like macros. Unfortunately some of the arguments are
evaluated twice - a sng with the C macro system. I find lower case
more tasteful than upper

x = clamp(x, 0, 255);

is far easier on the eye than

x = CLAMP(x, 0, 255);

The upper case gives the macro an emphasis it shouldn't have.

I have to disagree with you there. And you have gone against years of
"standard" in the C world.

Macros are nearly always upper case in the legacy code systems I have
been involved in.

[Kelsey Bjarnason]

[snips]

On Mon, 06 Aug 2007 20:55:52 +0100, Malcolm McLean wrote:

However there are some thigns you fail to appreciate. For instnace I suggest
using negative sizes to indicate "data fialed to compress".

Marvellous. You also use them to specify magic values going *into* your
compression routines: int squiz(void *buff, int size) or some such.
Since this means that one can no longer use legitimately-sized buffers
safely with your code *and* your code obviously expects magic values, the
code is nowhere near as clear or as safe as you seem to think it is.

Another thing you fail to appreciate is that compressed data is
inherently a binary format, and ought to be a portable binary format. So
the size integer has to be stored as a fixed number of bytes, with fixed
endianness.

So?

So a size_t, with size unknown, isn't an appropriate type.

Good. How big's an int? Hmm... 16 bits here, 32 there, 64 somewhere
else... and 36 bits on at least one implementation, IIRC. Which of the
umpteen allowable and unknown-at-design-time sizes is the known size?

Oh, right, none of 'em. So much for that argument.

However you draw the conclusion that because you disagree with the
decision over size_t, there are weaknesses, which you lack the ability
to discover, within the rest of the work. That seems to me pure bluster.

Err... no, that's not what I said. I said that there is absolutely no
justification for using int instead of size_t in a size context - something
you have yet to support - and this is a very, very bad design decision;
given that you've made such a bad decision here, it's simply to be
expected you make other such decisions elsewhere. Can one, with effort,
discover them? Very likely.

Given the choice between doing so and choosing someone else's work, work
which doesn't make such errors up front and in your face, work which
actually gives the impression that the author cares enough to do things
safely and properly, which should one prefer?

You, apparently, prefer works where there are some concept failures
smacking you in the face telling you you can't rely on the author's
judgement. Me, I prefer works where the author instills a sense of trust
by doing things right. I'm funny that way.

Oh well. None of this is topical anyhow, we should prolly kill the thread.

[Kelsey Bjarnason]

[snips]

On Mon, 06 Aug 2007 18:48:30 -0400, Eric Sosman wrote:

The chapter closes with an argument that putting code
in libraries that can be shared by many programs is a Bad
Thing; the "right" way to re-use code is to paste a copy
wherever you happen to need one. (No, I am not making this
up!)

Oh good goat, I managed to miss that bit. 'Scuse me while I go and cry in
my coffee a bit.

[Kelsey Bjarnason]

[snips]

On Tue, 07 Aug 2007 00:17:02 +0100, Malcolm McLean wrote:

The non-conforming implementation is an example of the book's style. It is
not written in C that happens to conform to the standards of the day

Guess what? We use compilers, a language and other tools that _do_
conform to the standards of the day. If you want to code in something
else, how about Pascal or BASIC?

>or from an unreliable source. The text says it's all right to use a
function you don't understand, provided you "trust the author" -- but
since the author is unnamed, we do not have the means to tell whether
he is trustworthy.

Exactly. If you are doing very advanced programming then either you have
to be brillinat and encyclopedic, or you have to use code you don't
understand. Not an ideal situation, but it is very often necessary to do
that.

Sure - yet we have absolutely no reason to trust the code, as we have no
clue where it came from.

x = clamp(x, 0, 255);

is far easier on the eye than

x = CLAMP(x, 0, 255);

Perhaps, but it lends itself to thinking of clamp as a function, not a
macro. Unless great care is taken with such macros to avoid issues such
as multiple evaluation, the results may not be what they would be if it
actually _were_ a function; CLAMP draws the attention that no, it is not
a function, it is a macro, so beware.

The upper case gives the macro an emphasis it shouldn't have.

It damn well *should* have it, as it is *not* a function, and given the
rest of the abysmally bad decisions taken in writing the code, I, for one,
have very little faith that macros are implemented safely in the book...
they *should* stand out, with big red flashing lights, shouting "Danger,
Will Robinson!"

Cut and paste is generally a far superior method. Libraries are fine if
you are implemeting something fundamental like OpenGL, but not when you
need a list of dependencies in your code. No one wants to link in five
libraries all with conflicting definition of "bool" just to use a few
string functions.

Why would you get _any_ definitions of bool in a _string_ library? Weird...