Dear DDJ,
In the "Letters" column of your December 1989 issue, Mark Nelson discusses U.S. Patent 4,558,302 entitled "High Speed Data Compression and Decompression Apparatus and Method." This patent was developed by Terry Welch, a former Unisys employee, and is owned by Unisys. According to Mr. Nelson, I have been quoted as saying that Unisys will "license the algorithm for a one time fee of $20,000." As a concession to the modem industry, Unisys has agreed to license the patent to modem manufacturers for use in modems conforming to the V42.bis data compression standard promulgated by CCITT, for a one-time fee of $20,000. This $20,000 license, however, is not a general license under all applications of our patent but is limited to the specific application discussed above.
Responding to the second paragraph of Nelson's remarks, Unisys is actively looking into the possibility that a large number of software developers may be infringing one or more of our data compression patents. We have only recently become aware of these potential infringers and the process of taking action will take some time.
Unisys is happy to accept inquiries from persons interested in acquiring a license to U.S. Patent 4,558,302. If your readers have any further questions, they should contact Mr. Edmund Chung of our licensing office, at 313-972-7114.
Robert S. Bramson
Unisys
Blue Bell, Penn.
Dear DDJ,
Dan W. Crockett's assertion in the January 1990 DDJ "Letters" section that structured programming requires that each functional node (or implementation unit) have only a single parent is alarming, and damned difficult to program in the real world. I think that he interprets the abstract requirements of structured programming a little too literally when it comes to coding.
As an example, consider a Pascal function, which formats dollar amounts for output. The function might take a real dollar argument and translate it to a "$nnn,nnn,...,nnn.nn" format, and be declared as function DollarFmt(v: real):string; The whole point of having the function is that it can be called from any procedure or function in a program; if the dollar amounts are formatted incorrectly we can first check to see if the error lies in DollarFmt, because it is solely responsible for performing the task. This is structured programming: Breaking down a task into smaller and smaller (and finally, logically indivisible) subtasks. Subtasks which perform similar or identical tasks can then be coded as a single (probably parameterized) routine.
Mr. Crockett wants program structure to be a B, Quad, or whatever tree, which is fine, but reality demands that the implementation be a threaded tree. Under the Crockett scheme we would be forced to write a separate DollarFmt for each caller (AmountDue_DollarFmt, AmountPaid_DollarFmt, ad nauseam)! The resulting plethora of duplicate routines would produce a worse debugging situation than Mr. Crockett thinks he'll have already -- never mind the maintenance nightmare.
The "single" restriction structured programming is the requirement that a single functional node not have more than one entry point within it, which is to say that all callers must enter through the same door. It is perfectly reasonable for a routine to have more than one caller -- without multiple callers there would be little reason for building a distinct procedure or function for performing the task.
Going back to the DollarFmt example: The structural decomposition of a hypothetical bill printing task might be
Print Bill
____________________________|_____________________________
| | |
| | |
List Line Items Calculate Interest Calculate Sum
| | |
Format Line Item Format Interest Format Sum
| | |
Format Amt Print Interest Print Sum
| | |
Print Item & Amt etc. etc.
It is (hopefully) obvious that "Format Amt," "Format Interest," and "Format Sum" should be programmed as calls to a single formatting routine, even though they are different tasks in the abstract.
There are dangers in interpreting any abstraction too literally. And there is that other thing, in the word of Will Rogers: "It's not what we don't know that hurts, it's what we know that ain't so."
Brook Monroe
Durham, North Carolina
Dear DDJ,
The listing of Mark Nelson's "Locate tool" in the January 1990 issue has a bug in the read_header_data procedure: It occurs in his calculation of image_size. The line:
image_size = (header.file_size_in_pages - 1) * 512;
should be replaced with:
if (header.image_length_mod_512 == O) image_size = header.file_size_in_ pages * 512; else image_size = (header.file_size_in_pages - 1) * 512;
The bug occurs when the actual image size is an even multiple of 512 bytes. As an example, consider an image size of 1526 (512 * 3). In this case, header_file_size_in_ pages would be three and header.image_length_mod_ 512 would be zero. Mark's code would produce an incorrect size of 1024 due to the decrement of header.file_size_ in_pages.
I had the opportunity of stumbling into this when writing a combination .EXE loader/relocator/unrelocator for a non-DOS-based embedded control system.
Thank you for your time and keep the interesting articles like Mark's coming.
Bill Trutor
Holden, Mass.
Mark responds: Bill has correctly identified a mistake in my program. I think I might have avoided this mental error with better naming of structure members. In any case, this is one of those program errors that occurs so infrequently (1 out of 512 links) that it can be extremely elusive, so thanks to Bill for pointing it out.
Dear DDJ,
In Jeff Duntemann's column in the December 1989 issue of DDJ, he mentioned his dream system under Windows 386. I have a question about this. I understand the languages and the PageMaker part, but could he expand on using Paradox? Do I understand him to mean that you use it to keep track of details about your data structures? Sounds interesting; could he elaborate?
Guy Townsend
CIS 73040,1671
Jeff's response: Hate to be a spoilsport, but mostly what I use Paradox for is to keep my various contact files a keystroke away. The notion of using a real-relational database to manage the gritty details of major development projects is a good one, but the language vendors are going to have to do the integration between the tools and the database. Some major vendors are indeed working on this, (still secretly) and you'll be seeing the results in DDJ when they surface.
Dear DDJ,
From time to time you must hear from disgruntled companies who feel that they have suffered at the hands of one of your writers performing a post-mortem with an axe.
Knowing, however, that Al Stevens is a venerable pilgrim to the hallowed halls of Bell Labs and a proponent of the object-oriented paradigm, we suppose that his summarial execution of our product was caused by a bit of underdone potato.
In his November "C Programming" column, just after explaining to his readership that he was neither rigorous nor controlled, he set about to describe the available C++ compilers and translators available for DOS. Without rigor or control he dismissed our Intek C++ product without evaluating the product at all! He chose instead to fault an example program that we provide with our distribution of the AT&T translator. This example program (which we supply the source to in the product distribution) invokes the C preprocessor, the C++ translator, and the target C compiler in succession. We supplied it to provide our customers with a convenient method of progressing from source to executable if they were invoking from the command line. The mentioned bug occurred only with DOS 3.3, and as with all software companies that stand behind their product with integrity, we supplied the fix to all of our customers long before Al's column went to print. Of course, Al didn't mention that other translator products don't offer anything like this and certainly don't supply the source to such a program.
Did Al mention that the near, far, huge, pascal, fortran, and cdecl keywords don't work with the AT&T distribution or with some other translator products but that they do with Intek C++? No. Ever tried to use a third party header file with some of these keywords in it or try to link to a library, expecting the results of these modifiers, Al?
Did Al mention that if one tried to compile any production size C++ source modules with other products that they would run out of memory? No. Maybe he'd rather make sure that all of his source files were less than 4K in size and that he could only include three or less header files.
Did Al benchmark the fact that the only product from among the group that he mentioned that will compile the AT&T C++ source distribution is Intek C++? No. (That's AT&T's definition of the robustness of a C++ translator implementation by the way.)
Please assure Al that Intek C++ will continue to have a future in the PC world. Our client list has many of the Fortune 500 firms among it. We also use our own product in providing factory automation applications to the major workstation and computer manufacturers in the country.
We feel like you would feel if in a review of magazines Dr. Dobb's was dismissed as not being a quality software tools magazine because it sounds like it should be a medical journal.
Mac Cutchins
Intek
Bellevue, Wash.
Al responds: My evaluation of Intek C++ consisted at first of the seemingly simple task of getting it to compile the hello.cpp program that comes with the translator. "Hello, world," nothing more, right out of the box. That simple task involved two days of frustration and several phone calls to Intek.
The Intek technical support person at first insisted that there was something wrong with my setup. The nature of the bug -- the translator worked every other time -- encouraged both of us to believe that. The compiler failed, I called, he made a suggestion, the compiler worked. I hung up, the compiler failed, I called, and so on. One of those times we changed operating systems, and the technical support person concluded that my copy of DOS 3.3 was the culprit. He must have remembered that episode and subsequently convinced you, Mr. Cutchins, but not me. The bug was identical for DOS Versions 3.0, 3.2, 3.3, and 4.0. Under 3.1, the bug is different, and hello.cpp just never compiles. When I reported these findings, your technical support person, by now tired of hearing from me, curtly announced that there must be some problem, that it would get fixed, goodbye, and thank you very much. If you fixed that bug, I never heard about it, before or after my column went to print. Until now, that is. I guess as a pesky magazine columnist with a free review copy of your pricey product, I don't rate an upgrade. Never once during all those calls did Intek suggest that I abandon the "example" CPLUS program and use the lower-level programs, which I now see is the obvious solution.
In my opinion, Intek C++ is underpackaged and over-priced. The skimpy 40-page spiral-bound manual devotes only 10 pages to installing and using the translator, has exactly two sentences about using it with Turbo C, has some critical typos (the C_COMPILER environment variable is misspelled, for example), and never lets on that the CPLUS program is a mere example to be used at one's own risk. Intek C++ fails to measure up to the standards of quality that PC programmers have come to expect in their language products. My assessment of your future in the PC market was based on my view of the cost and quality of the Intek C++ software, documentation, and support and of the expensive hardware/software foundation necessary to use it. I stand by that assessment. If you believe that Intek C++ has improved substantially since my evaluation of it, I'll be pleased to give it another look.
Dear DDJ,
Recently I completed a graphics course, so I read with interest the January issue article by Robert Zigon dealing with generation of circles. I found the article to be a clear and well written exposition of the problem. However, any algorithm based upon the parametric representation of a circle must involve significant overhead in the form of floating-point calculations. A superior algorithm developed by J.E. Bresenham some years ago avoids such overhead.
The Bresenham algorithm makes use of the fact that screen coordinates are integer valued, so it should be possible to select the circle's coordinates using only integer arithmetic as well. Use of only integer arithmetic is the key to the efficiency of the algorithm. The algorithm is used to advance along the perimeter of the circle, selecting the adjacent pixel which is nearest to the circle at each step. Because of circular symmetry, it suffices to determine only one-eighth of the circle using this technique.
An excellent derivation of the algorithm is given in the text Computer Graphics by Donald Hearn and M. Pauline Baker (Prentice Hall, 1986). The derivation depends only upon elementary algebra, but may require somewhat greater mathematical maturity due to the notation used. The text also presents Pascal code for the algorithm. Another reference, which gives a limited explanation and a C code implementation of the algorithm, but which does not attempt to derive the algorithm, is Graphics Programming in C by Roger T. Stevens (M&T Books, 1988).
Joseph M. Hovanes Jr.
Pittsburgh, Pennsylvania
Dear DDJ,
Here's 20 cents to fan the Flames of T.S. Kuhn's book, The Structure of Scientific Revolutions. It caused me to go cold turkey re. the tube for three days.
Martin Tracy reaffirmed my belief that Forth in its dialects offers the best presently available forum for discussion of "discrete mathematics" and the foundations of computing science. But I would like to see his work in the form of a bootable operating system and not a guest under another commercial product.
I confess that my own present work, "simpli-Forth," which is strongly tied to the 6502, still requires a fig-Forth boot to get off the ground. Perhaps if I work, I can learn enough about target compilers to create my own boot codes.
It seems to me that small operating systems with too-early emphasis on hiding or transportability may not be in the best interest of learners who seek to know in detail how their computing systems work. I would like to see small Forth systems place the user in a programming environment which makes plain the processes of his machine. That is why calls to DOS seem misplaced to me; I'd prefer that all of a small Forth system be available to the decompiler and user.
Would not a system for the programming of "smart" peripherals be more useful and general by omission of read-only memory? One could imagine modified error-handling, perhaps by redirecting the error-message stream to the calling device and transmitting a raise-error-request to it. But I remain convinced that the "smart" external should be executing a standard and expandable Forth kernel, albeit a minimal one, and that communication with it should be in the form of a standard, interpreted input stream.
The user of such a device could then load codes indicating how the forthcoming data is to be handled, followed by the commands to be executed and the data (e.g., 80 PRINTLINE THE QUICK BROWN FOX JUMPS OVER ...). At the end of such a session, some command such as DONE would then forget the loaded object-behavior back to that formerly executing. Instead of relying on ROM to make our machines robust we would enter a new arena of opportunity for flexibility. It is time for a generation of peripherals which can follow the lead and dance.
On another subject, Brodie encourages us, "Use dumb words." One of the major differences between fig-Forth and Forth-83 is in the use of the STATE variable and its effect on words such as ' and LITERAL. In the process of learning to use STATE-sensitive words correctly, I, too, have been hopelessly confused from time to time. But the fully interactive capabilities possible in a modern Forth machine may require STATE-sensitive behavior.
For this reason I chose to write SIF (STATE @ IF) which may be used:
: TEST SIF COMPILE THEN DO-IT;
IMMEDIATE
which will cause TEST to compile DO-IT if compiling else execute it (COMPILE is not IMMEDIATE). Although this example makes TEST equal to DO-IT, more-useful examples can be drawn. Another word might be ?COMPILE that would combine the effects of SIF, THEN, and IMMEDIATE and be used: : TEST ?COMPILE DO-IT ; so that all words using ?COMPILE would automatically be made IMMEDIATE.
"Use dumb words" is sound advice. But some quite interesting capabilities arise only when one uses correctly written words with STATE-sensitive behavior.
Jon W. Osterlund Greeley, Colo.