Dear DDJ,
I have been following the software patent issue since you published the November 1990 article on the subject. Even though I agree with the League for Programming Freedom, I believe there is another threat to the American software industry, which is currently being ignored.
The current state of software development in the U.S. can be compared to furniture manufacturing during the Industrial Revolution. At the beginning of the Industrial Revolution, someone would either handcraft his own piece of furniture or go to a master craftsman and have it custom made. As the Industrial Revolution came into its own, the consumer could buy furniture from a factory. Of course, furniture from a factory was not custom built for each consumer, but the consumer could purchase furniture at a lower price.
Most software-development teams can easily be described as groups of master craftsmen, hand fashioning every part of the entire system they are building. As master craftsmen, we will often argue that each part must be "optimized" (or handcrafted) in order to precisely fit the customer's needs. We need to move away from the art of software development and develop software engineering methodologies which work in the real world of software scheduling and development costs.
The beginnings of this methodology can be found in the object-oriented paradigm. But OOP will fail if the software development community fails to deal with the "Not Written Here Syndrome" (NWHS). NWHS will prevent the software industry from gaining the reuse benefits of OOP. Many programmers simply do not trust any software components they did not write themselves. Of course many of these software components are inadequately designed, implemented, tested, and documented to be of any use in the real world.
Changes in the software-development community must begin with the individual programmers. Each of us must spend the time necessary to analyze, design, implement, test, and document software components which can be reused. We must not allow ourselves to fall into the trap of getting the system working today and putting the rest of the work off until tomorrow. We all know that tomorrow never comes.
I have not mentioned a single programming language here, since I believe good software engineering can be accomplished in any language, even though some languages do encourage better software engineering techniques than others.
If we don't act to correct this problem, the U.S. may lose its world dominance in the software industry, just as it lost its dominance in the automobile industry. We now export approximately $22 billion in software, accounting for 80-85% of the world-wide market. This is threatened by the Japanese effort to develop a "software factory." Already, the Software Engineering Institute has rated several Japanese companies at level five in their process-maturity scale. Only a few American companies have been rated at level three.
We must act quickly to foster software-engineering practices, or ten years from now we may be wondering why the U.S. does not dominate the world market for software anymore.
David M. Tannen
Tampa, Florida
Dear DDJ,
I must add my bit to the great MOD debate catalyzed by Jeff Duntemann beginning in the November 1990 "Structured Programming" column.
I was in my first year at the University of Cape Town in 1980. One of our first assignments was to write a program to return the day of week for a date using this same algorithm (using Fortran on a punch card chewing UNIVAC). I used the following to calculate a0..n-1 style MOD:
day_of_week = mod(mod(mod (value,7) + 7,7)
The professor got quite upset, as he was sure that MOD would always return a 0..n--1 value, as any sane person might expect. He only gave me 90% for the assignment because of this. Arguing didn't help. The PhD wasn't listening to some trumped-up 18-year-old! So I proved my point with a few test programs and was finally awarded 109% (110 less 1% because I didn't comment the use of a double MOD). Well, that's the way I remember it; the story has probably improved with age.
I still maintain that this is the best way of handling the problem. In the February 1992 "Letters" column, David Hall proposes two methods. The first (k:=i MOD 7; if k < 0 then k:=k + 7;) I personally don't like because I feel that IF... THEN... ELSE... should be avoided in calculations unless it is an intuitive part of the algorithm. Here it is being used to circumvent an illogical language feature. The second method (QuickBasic INT) relies on a quirk of a particular language, whereas the first (bring on the MIDI orchestra here) has been used in Fortran, Pascal, C, Lisp, and PLM. The second method is probably more reliable because there are no IFy...THENy...ELSEy... chunks of code that go untested until the 1997 summer solstice (or whenever).
Charles Manning
Cape Town, South Africa
Dear DDJ,
Nicholas Wilt's informative article "Assembly Language Programming for the 80x87" unfortunately uses a bad example--calculation of both quadratic roots from the equation we all learned in elementary algebra. One root or the other inevitably suffers loss of precision due to subtraction of (b2-4ac)1/2 from -b. If ac<<b2, this loss can be severe, since the two terms in the subtraction are nearly the same size. Good practice is to determine the sign of (-b) and then calculate one root r1 using that same sign ahead of the second term. The other root r2 is then easily obtained from r1 x r2 = c/a.
There is a common misconception that with high-precision arithmetic, serious errors from this and similar sources are rare. However, the writer of a general-purpose routine cannot know the circumstances under which it will be used. It is easy to devise examples where b2 might exceed 4ac by many orders of magnitude, and a user of a routine ought not to have to perform additional tests or to change routines in the middle of a set of data.
A second misconception is that the root that suffers subtractive precision loss is intrinsically less well-defined by the data. This is not the case. As the relationship between the two roots given above implies, both are often known to the same relative precision. The precision loss has nothing to do with the data--it is an artifact of the calculation.
Wilt's article was a good introduction to math-coprocessor programming. Perhaps he could be persuaded to provide an amended quadratic-root routine.
Brad Thompson
Saint Peter, Minnesota
Nicholas responds: Brad is correct, of course. I was remiss not to consult standard references before implementing the routine. To remedy my oversight, and to comply with his request, I have written a new solve_quadratic() routine that is more numerically stable.
The new routine is from Numerical Recipes by Press, Flannery et. al (Cambridge University Press, 1986) and works as follows. The roots of a quadratic polynomial ax2+bx+c=0 can be given in terms of an intermediate variable q, as shown in Figure 1.
q = - 1/2[b+b\/--b2 -4ac]
The roots are then q/a and c/q. The technique is almost identical to the one given by Thompson, but uses a and c to arrive at the two roots separately rather than computing the first root and deriving the second from it.
Example 1 shows the new solve_quadratic() routine. My thanks to Brad for bringing this issue to my attention.
; quad.asm: quadratic-solving function callable from Borland C++.
; Copyright (C) 1991, 1992 by Nicholas Wilt. All rights reserved.
This routine
; is modified from the version published in Dr. Dobb's Journal, March
1992. ; It's more numerically stable per Brad Thompson's suggestion. The
technique
; is described on pg. 145 of _Numerical Recipes_ by Press, Flannery
et al.
.MODEL LARGE,C
.CODE
; int solve_quadratic (double a, double b, double c, double *x1, double
*x2);
; solve_quadratic takes the coefficients of a quadratic polynomial and
finds
; roots of that polynomial. If there are two real roots, it writes
them back
; to x1 and x2 and returns 1. If there are no real roots it returns 0.
PUBLIC solve_quadratic
solve_quadratic PROC A:QWORD,B:QWORD,C:QWORD,X1:DWORD,X2:DWORD
; Comments show stack contents: Stack top is at left.
sub sp,2 ; Allocate local
mov bx,sp ; and point BX at it
fld C ; c
fld A ; a c
fld B ; b a c
fchs ; -b a c
; We're going to need the sign of -b later, so do the
; test and store the resulting status word in DX.
ftst ; DX <- sgn (-b)
fstsw ss:[bx]
mov dx,ss:[bx] ;
fld st ; -b -b a c
fmul st,st(0) ; b^2 -b a c
fld st(2) ; a b^2 -b a c
fmul st,st(4) ; ac b^2 -b a c
fadd st,st(0) ; 2ac b^2 -b a c
fadd st,st(0) ; 4ac b^2 -b a c
fsub ; b^2-4ac -b a c
ftst ; Return 0 if negative
fstsw ss:[bx] ;
mov ax,ss:[bx] ;
sahf ;
jae FindRoots ;
fstp st ; Clear FP stack and return 0.
fstp st ;
fstp st ;
fstp st ;
xor ax,ax ;
jmp short LeaveQuadratic
FindRoots:
fsqrt ; sqrt(b^2-4ac) -b a c
xchg ax,dx ; Negate if -b is negative
sahf ;
ja FindR1 ;
fchs ;
FindR1: fadd ; (2q = -b-sgn(b)sqrt(b^2-4ac)) a c
fxch st(2) ; c a 2q
fadd st,st(0) ; 2c a 2q
fdiv st,st(2) ; c/q a 2q
les bx,X1 ; Write out first root
fstp qword ptr es:[bx]
fadd st,st(0) ; 2a 2q
fdiv ;
les bx,X2 ; Write second root
fstp qword ptr es:[bx]
mov ax,1 ; Return 1 to say there are roots
LeaveQuadratic:
add sp,2 ; Deallocate local
ret ; Return
solve_quadratic ENDP
END
Dear DDJ,
I'd never thought about a generic swap macro until I read Greg Renzelman's letter in the April 1992 "Letters" column. While I like his macro, it's not true that swapping requires a temporary variable; I've come across a swap implementation that doesn't. The trick lies in using exclusive ORs to "pass the values through each other." Based on that, I've modified Greg's swap macro to eliminate the temporary variable; see Example 2 .
=define SWAP(a.b) \
{ \
unsigned int i; \
char *aptr = (char *)&(a), *bptr = (char *)&(b): \
for (i=0; i<sizeof((a)); i++, aptr++, bptr++) { \
*aptr ^= *bptr; \
*bptr ^= *aptr; \
*aptr ^= *bptr; \
}
}
or, more compactly,
#define SWAP(a,b) \
{ \
unsigned int i; \
char *aptr = (char *)&(a), *bptr = (char *)&(b): \
for (i=0; i<sizeof((a)); i++, aptr++, bptr++) { \
*aptr ^= *bptr ^= *aptr ^= *bptr; \
}
Rob Ewan
Whitby, Ontario
Dear DDJ,
In my October 1991 article, "Proposing a C++ String Class Standard," I promised that feedback on the article would be sent to the ANSI committee on the C++ string class. As it turns out, the proposal to include the string class in the C++ standard library was turned down, but I have passed on the following feedback:
Budd Lake, New Jersey
The computer and software industries have had a spate of tenth anniversaries lately: Lotus, Sun, Adobe, Autodesk, Compaq, Silicon Graphics, and Symantec. It seems the company baby boom generation spurred by the personal computer phenomenon is reaching early maturity. It would be tempting to pine for the West Coast Computer Faire, software in Ziploc plastic baggies, Tiny Basic on the 68XX, and the wild west days of computers and computer publishing, if nostalgia weren't so misplaced.
I will allow myself one brief reminiscence. I remember meeting with Mike Swaine for the first time in late 1983 at Scott's Seafood in Palo Alto. M&T had been in business a little over a year as the U.S. sales office for Markt & Technik, our German parent company. We were eager (if not ready) to enter the U.S. market for computer publications. A license and subsequent purchase of Dr. Dobb's Journal from the People's Computer Company was our immediate goal. Mike was the prospective editor of DDJ (and continues as a key contributor and editor-at-large to this day). I had read Fire in the Valley, which Mike co-authored with his then-colleague at Infoworld, Paul Freiberger. In Fire, Mike had documented the awkward beginnings, obsessive characters, and bold sense of mission that typified the Homebrew Computer Club and other seminal happenings in microcomputing, as we called it then. Mike and I talked warmly about the potential for software development and for DDJ. Actually I did most of the talking, which is typical in a pre-beer Swaine discussion, but he nodded, raised his eyebrows enthusiastically, and stroked his beard a lot. I felt deeply connected, not just to the historian, but to the history of the PC. We talked about continuing the DDJ tradition of sharing information among interested programmers, imagining the works they would achieve.
Much more history has unfolded since those days. We live in a world with more than 100 million personal computers. More than 30 million more will be shipped this year (Infocorp). Most office users are now hooked to networks and four out of five will be by 1994 (says the Yankee Group). There are more than one million professional software programmers and analysts in the U.S., says the government. M&T's audience has grown from 18,000 to more than 300,000 paying readers, all professionals in software development or network systems design and integration.
Lately, it seems the bloom is off the personal computing rose. Doubt about the productive benefit of computers is growing. Times are tough. Where is the spreadsheet for the 90s? Why are hardware companies losing so much money? You can sense the self-doubt in a proposed computer industry seminar topic, "Can Technology Take Us to a New Level of Significant Opportunity?"
If we view the creative, economic, and practical achievements of the last ten years as a basis for new innovation, a resounding "yes" to this question follows easily. Tens of millions of graphical, networked PCs are a tremendous potential resource for programmers and system designers in the decade ahead. Millions of portable devices with pen interfaces and wireless communications are also soon to come. They represent a test-bed for software that delivers a "connected Dynabook." Embedded systems are another vast area of opportunity. The possibilities are getting really interesting. The fact is, we have just begun to address the world's challenges with software, because we are just starting to have an infrastructure upon which to solve group problems.
I was speaking with a colleague recently who said, "Software is like the wheel." She went on to mention how much of the urban, industrial development of mankind followed from understanding and applying the power of the wheel to the physical world. Software is like a wheel for the mind. It presages an information, communication, and creativity-based future that is hard to foresee. Historically speaking, software has just been invented. M&T, by serving you with technical information, is committed to its further spread for at least the next ten years.
Copyright © 1992, Dr. Dobb's Journal