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

[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.un iv-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)gma il.com |
----------------------| I do not currently read any posts posted through
sdf.lonestar.or g | Google groups, due to rampant unchecked spam.

[REH]

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

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******** *************@i rq.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******** *************@i rq.org...

>Congratulation s! 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*******@btin ternet.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)gma il.com |
----------------------| I do not currently read any posts posted through
sdf.lonestar.or g | Google groups, due to rampant unchecked spam.

[Malcolm McLean]

"Keith Thompson" <ks***@mib.orgw rote in message
news:ln******** ****@nuthaus.mi b.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**********@p obox.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 disintermediate s. 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**********@p obox.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