Your recent indication of excellence of the book Numerical Methods for Scientists and Engineers is quite true; however, it is out of print by McGrawHill Co. Today's prices would have the book at about $65, if it were in print by that publisher. However, the same book is available through Dover Publications, Inc. at $14.95! Many books of scientific noteworthiness are available through Dover at considerably reduced prices. Anyone needing an inexpensive source for math, physics, or astronomy books should check out Dover first. The book prices average $7.00. For scientific books that's almost free! Their Science and Math Catalogue is free, too. It's nice to find a publisher that isn't out to eat one's paycheck. Their address and phone number are:

Dover Publications, Inc.
11 East 2nd St.
Mineola, NY 11501
1-516-294-7000

Sincerely yours,

Jerry Rice
504 Eastland St.
El Paso, TX 79907

That's good news. Thanks. — pjp

To P.J. Plauger (via e-mail):

In his "Inside RISKS" column (page 154) in the July 1990 issue of the Communications of the ACM, Peter G. Neumann states that a C program containing a "break statement within an if clause nested within a switch clause" is either "a programming error, or a deficiency of the C language/compiler, depending on your taste, in that the intervening if clause was in violation of expected programming practice." Since, according to Peter Neumann, this bad programming practice was the cause of the AT&T January 15, 1990 ESS switching fiasco, your readers would certainly enjoy any comments you might have on Pete Neumann's statement about C.

John K. Gotwals
Computer Technology
Purdue University
gotwals@vm.cc.purdue.edu

I vaguely recall that the actual error involved a dropped line that resulted in the quoted construct, but I could be wrong. I certainly write an occasional if ... break within a switch, having no religious objections to multiple exits from a block of code. That, to me, is neither a programming error, nor a deficiency in the language, nor a deficiency in any compiler. Tastes differ, of course.

We still live in an era where we demand so much performance from our software and hardware that we cut corners on code checks. We also demand such rapid development that we cut corners on validation and testing. AT&T should get high marks for responding well to the problem. That it happened at all is, I think, inevitable. Some people will scapegoat C for this episode. The rest of us know better. — pjp

Dear Sir:

With regard to the letter from Bruce Wells, and your reply in the "We Have Mail" section of the August 1991 issue of The C Users Journal, I have a request.

You wryly mused over the "practical effect" of making English official, thereby observing that the issue is rather pointless for any constructive purpose.

Unfortunately, this issue is worse than pointless.

Let us be blunt. For a variety of historical and geographical reasons, the U.S. has many of the characteristics of an insular culture. Many of its people speak only one language, and display the obsessive concern with cultural homogeneity that one normally associates with certain peoples in third world countries whose real exposure to other cultures is extremely limited.

This situation has begun to change over the past few decades, as more geographical areas have become more culturally diverse. Predictably, this growing diversity has prompted a backlash among certain groups.

Sadly, official English is not a real issue, but more tired camouflage for the real underlying issues of fear, racism, and cultural intolerance. The world of official English has, to quote William Gibson, "all the sinister fruitiness of Hitler Youth propaganda." To make a thing official is, by definition, to promote that thing at the expense of other things, to limit opportunity rather than expand it, to close minds rather than open them.

Cultural diversity in our own country is real, a living and vital experience for millions of Americans, every day. As a personal example, I live in a town where German, not English, is traditionally spoken. I live in a state where Spanish is spoken by millions of people. I myself speak Spanish, simply because it is an essential tool for living where I do. Earlier in my life, I was exposed to the French Cajun culture of Louisiana, and French Canadians working in Michigan. These are simple slices of everyday American life, not the exotic hothouse experiences of an international jetsetter, or the academic concerns of an ACLU attorney.

My question for the proponents of official English is simple — what do you intend to do? Do you actually intend to enforce the use of English in some sense, or not? If enforcement is intended, what do you intend to do that would enrich my life, rather than impoverish it? Burn books, or merely ban them? Perhaps we might limit ourselves to stamping certain literature (you know, the wrong kind...) with a warning, "This material could be hazardous to your ignorance." Or we might just frown on (officially) those authors, past, present, and future, who write in other languages and perversely persist in expressing ideas that we didn't hear at the mall today.

And if you don't intend to do anything to restrict communication to a purely English channel (sigh, yes, it was intentional...), then what constructive purpose does it serve? Is the intention merely to bask in the knowledge that the language you speak (by accident of birth) is official, while others are not, and are, therefore, suspicious, non-conforming, and, somehow less? Assuaging your paranoia carries a fearfully high price tag.

And my request? The next time this issue comes along, please give it the response it deserves. Deflection, however gently deft, will not do. Stomp on it.

Sincerely,

Lance Latham

Okay, I won't deflect it gently this time. But I'm also not inclined to turn this letters column into a political forum just because of a chance remark I made in one column. This is a magazine by and for C users, you may recall. Once and for all, here's my response to your diatribe:

Americans do not have a monopoly on bigotry or racism. I have traveled the world extensively and can attest that the problem is universal. If anything, we anguish about our shortcomings louder than others. We work harder at correcting them than many.

America has proudly been a melting pot for centuries. Many countries defend their cultural homogeneity by excluding others. We don't.

A melting pot requires a bit of melting. It's one thing to speak Spanish or German at home, it's quite another to demand that tax money be spent to support your language of choice. Should official forms be available in multiple languages? Then how about textbooks and school teachers? Who chooses the supported languages? Who is liable if an American citizen, officially educated speaking only Greek, misreads an English road sign or a warning label and gets injured?

If English is the official language, you have an argument against burdening states and municipalities along these lines. They may still choose to support significant minorities, but they have a defense against certain kinds of legal bullying that has become popular.

I have heard no attempt to outlaw cultural diversity, as Mr Latham suggests. Were that to happen, under this banner or any other, I would be at the barricades fighting for freedom of expression alongside many others.

Some people mistakenly assume that anything not made mandatory must be forbidden. (I heard arguments of this ilk frequently in C standards meetings.) English can be made official without making Spanish illegal.

Enough said. — pjp

Dear Editor,

The letter to the editor page 126 in the August 1991 issue is the first discussion of bit variables I have ever seen. I'm not talking about bit fields. Those programmers that don't know the difference are a disgrace to the profession. Bit fields are convenient for setting a small number of yes or no type switches. For example, border, shadow, reverse video, mouse, etc.

However, there are some useful theoretical concepts that require arrays of bits. For example, a connectivity matrix. Remember Warshall's algorithm for computing transitive closure. The values in these matrices are either zero or one. Sure you can use bytes to represent them if you don't have too many. And sure the bit test operations on an 8088 chip are inefficient, but most of us professionals now have 386 chips, which have an efficient bit test operation, finally.

So, the question is: Why do we have to use char arrays and specify several shift operations to test the bit we are interested in? The C compilers don't generate efficient code for this. It's horrible code, considering what it could be if the C language had a bit type and bit arrays were valid. PL/1 had this concept.

I would find the code much more readable if it were to look like this:

int row, col;
bit matrix [100,100];
...
if (matrix [row, col]) ...

int row, col, n_cols, d;
char matrix [100, 13];
...
d = row*n_col s + col;
if (matrix [d >> 4] << (d & 0x000F)
   >> 15) ...

Sincerely,

Paul Mann,
Prosoft
399 E. 10th Ave.
Eugene, OR 97401

The Numerical C Extensions Group, X3J11.1, has been entertaining at least one proposal for bit arrays, as I recall. — pjp

Dear Sirs:

I have a favor to ask. I am trying to locate the C or C++ code equivalent to the STRIG and STICK functions that BASIC has for reading the input for the gameports. Can you tell me where to find these? Perhaps you can print a listing in the magazine.

Yours,

David Voit
D. Voit Associates
Box 1206
Lodi CA 95241

Anybody? — pjp

Dear Editor,

Ref: The concern for "state of the art."

I generally like the articles as much as your readers' comments on your articles. I think if you follow a particular thread over the last 10 years or so, you would be in a good position to give the "state of the art" in a few fields. Bundle the articles and the readers' comments together by subject.

I would be very much interested in such "state of the art" packages on topics such as

• ordered lists (binary trees etc.)
• MS-DOS interface
• searching and sorting
• encryption
• programming style

Sincerely yours,

L. Engbert
Engbert UB
Taunusstrasse 8
D-6384 Schmitten 1
Germany

The state of the art in those fields can be pretty hard to summarize. It can also be very hard to present for a varied audience without appearing to backtrack from time to time. — pjp

Dear Editor,

Ref: Looking for...

Has any one of your readers got the source to the Turbo C function library (which Borland is no longer selling)? I want to know what the functions are doing. Documentation is often hopeless. Plus I want to rewrite the one or another function in assembler. Or does anyone know of other sources for C/assembler source to standard C function libraries?

Sincerely yours,

L. Engbert
Engbert UB
Taunusstrasse 8
D-6384 Schmitten 1
Germany

Ahem. I happen to have source to the Turbo C++ function library, which I suspect is a superset of what you want. Since this is a licensed product, however, I wouldn't pass it on. Nor would I encourage anyone else to do so.

On the other hand, you can now get complete source for the Standard C library by buying my latest book, The Standard C Library. It has no Turbo C specific functions, but what's there can be used much more freely. The code diskette is available from R&D Publications, publisher of this journal. — pjp

Dear Editor,

Ref: Article "Optimizing Binary Trees" by Bruce Terry, in the June 1991 issue.

The idea presented in the article is quite unique. The following comments do not detract from the value of the "folding" algorithm, which is quite useful — useful except in the case on which it is used!

There is a main "non sequiter" in the first few lines of the article. The rest follows from the wrong conclusion arrived at here, which is that "there are advantages to optimizing a binary tree after it has been built. First, adding a node to the tree is still simple and efficient. Second, no additional memory is required" (for the record which holds the balancing information, such as in the AVL tree).

If it is worth having a balanced tree, then it is worth having at any time. Conversely, if it is of no use while building the tree, it won't be of use thereafter! The question is, how often do you step in and correct any imbalances? The algorithm's single major defect is that it doesn't say just when (and how often) balancing should occur! That is, the most important element which could qualify the presented algorithm as a balancing algorithm is missing!

(All the following comments are related to this basic shortcoming.)

For one, we program for the worst case. The main reason for using balancing algorithms is to prevent any degradation: make sure that the nesting depth does not exceed a number x. The necessity for such balancing can be demonstrated using the code provided in the article: The function worstcase calls itself recursively. Unless I make sure that the randomly-built binary tree does not exceed a given pre-determined nesting depth, there is a risk that the nesting depth comes close to the number of nodes in the tree ("linked list" degradation), so that the routine calls itself recursively for each node. For a list holding 20,000 elements, this would multiply the stack requirement of the function worstcase by 20,000!

Such a safeguard can be built into the program. Trigger the "folding" algorithm as soon as we hit a nest-level x. But then it is probably preferable to watch nesting depths by subtree, as we save the hassle of rebalancing the whole (I) tree each time. Now tell me when to rebalance a subtree. We are not too far away from the shape of so-called "tree-balancing algorithms" which are implicitly discredited in the article as not "simple and efficient".

For two, it is hard to tell when a tree is still being built. So much of the article is a semantic problem. In real life, a tree is built, modified, added to. Building symbol tables for compilers is perhaps an exception. Is this perhaps the example, which the author is thinking of?. But if so, the considerations above apply. Risk of degradation during the process of building the tree, is too high. One would like to keep a watch during the build-up.

We don't let a child run out into the street, and tell him the rules after he or she has (hopefully) returned safely.

Sincerely yours,

L. Engbert
Engbert UB
Taunusstrasse 8
D-6384 Schmitten 1
Germany

The pattern of usage can strongly affect where best to invest in code complexity to save execution time. — pjp

Dear Mr. P.J. Plauger (via e-mail),

I am a subscriber to CUJ and just wanted to let you know that I am very happy with the content and format of it. I am a student here at UMBC (University of Maryland, Baltimore County) and am just really starting to become proficient in C. I really enjoy the language and your magazine makes it even more enjoyable with many good examples. One of my favorite features is your reviews of different utilities from news groups on Internet. Being a student, I like to play around with different hardware and software to help me learn things and figure out problems. The news groups really have come in handy on many different occasions and your reviews help me sift through the millions of entries and find a lot of things I'm looking for. Basically I want to say thank you for an excellent journal!

Robert Allen Gottlieb
gottlieb@umbc5.umbc.edu (Internet)
gottlieb@umbc2.umbc.edu (Bitnet/Internet)

Glad to hear you like what we're doing. Sometimes the critical letters loom so large that we lose perspective. It's nice to know that somebody out there is happy. — pjp