(x/(y2)+2*y)/3.
Dear DDJ,
I found the article "32-bit Floating-point Math" by Al Williams (DDJ, June 1993) both interesting and useful. At first, the answers the package gave to test calculations were more than adequately accurate. But eventually I noticed that some calculations were wrong, not just inaccurate. I haven't had use for the fdivxy function, so I can't vouch for or condemn it, but I've found problems with both the faddxy and fmulxy routines.
faddxy has two errors. A minor one, as long as the memory model remains small, is that it ends with a POP DX instruction when a POP DS is what's needed. The more serious problem is that when both arguments are negative and the addition results in a cleared sign bit, faddxy does not recognize that an overflow has occurred and so does not perform the special handling required.
fmulxy has one error. When adjusting the radix point after multiplication, it can attempt a double right shift by 32 bits (SHRD, EAX, EDX, CL). Since the SHRD instruction uses only the least significant 5 bits of the third argument, this is equivalent to shifting by 0.
Example 1 illustrates very conservative modifications to the original code which eliminate the problems I've mentioned.
Thomas Senchyna
San Rafael, California
Al replies: Thanks for your interest in FPM. Your observations are correct. One of the difficulties in writing numerical software is testing all the possibilities.
Although your changes to FPM were correct, I took the liberty of changing them somewhat to make the resulting code shorter (see Example 2).
Dear DDJ,
In his letter in the May 1993 DDJ, David Smead states that programming productivity won't be boosted much by any programming language. Does this mean that we can program in assembler and still have programs written as fast as in C or some other languages? Can we extend this argument about C++ and C to say that since C is translated into native machine language ultimately, we don't need C?
A programming language is a notation that lets me state the solution to the problem I am trying to solve which, incidentally, is also understood by the computer. We can describe the solution to any problem using a Turing machine whose basic operations are extremely simple, but no one programs for Turing machines. The first step in solving any problem is to understand it and be able to describe it using a convenient notation. To say that it does not matter what notation we use to state and solve problems seems extremely simplistic.
In spite of nearly nine years of programming in C, I'm neither a fan of C and C++, nor do I hate them. But I do know that to solve the problems we are solving today, C is woefully inadequate. Having written an RDBMS engine in C with OOP mechanisms handcrafted, I have come to appreciate the usefulness of language constructs. Any new notation (by which I mean the syntactic constructs and their semantics) go a long way in the readability of a software. I would gladly take C++ over C, in spite of C++ being a complex language. I also appreciate the fact that mere language alone does not guarantee programming nirvana. But in the hands of a trained person, a language with powerful notational abilities can make a difference by providing built-in support for things that would have to be poorly hacked in a language like C.
We should recognize the fact that new languages are something more than just a fad. While C++ and Objective-C are quite similar in concept, they provide a significant expressive power compared to C or Pascal. Each new class of languages seems to emphasize a different style of programming and I don't see why we should not welcome a language that offers a more powerful abstraction mechanism. It is true that we don't see all the details behind such abstractions, but I see that as an advantage.
Let's not be overly concerned about new languages and their features. We do need to be liberated from the highly procedural, unforgiving, and poorly documenting languages like C and instead see a language that gives us mechanisms which aid productivity. (I am talking about a language which alerts me to errors that can be detected by source analysis, garbage collection, hiding pointers, incremental compilation, source-code portability, and so on. Language researchers have made a lot of progress in these area and we may soon have these features without the performance penalty.) We have come a long way from Fortran and Cobol, but we do have a long way to go yet.
M. Prakash
Moline Illinois
Dear DDJ,
I was glad to see a negative book review in Al Stevens's "C Programming" column (DDJ, October 1993). I'm not saying I agree with it--I haven't picked up the book. I have, however, spent a lot of money over the years on this kind of book, have learned quite a bit from some of the better ones, and have a pile of some of the not-so-good ones. I have learned to read book reviews and know that, if over 30 percent of the review is spent discussing the bad aspects of the book, the book is a piece of trash. I found it very refreshing to read Al's undiluted thoughts about this particular work, and especially enjoyed his speculation about the probable interaction between the book publisher and author. I consider book reviews to be a service for which I justify part of the subscription prices I pay to several software magazines; and I consider negative reviews to be every bit as important as rave or mixed reviews. If I had a Macintosh project coming up and stumbled across this book before I stumbled across Al's review of it, I might have spent more of my money for another entry in my pile of door stops.
Thomas J. Murphy
Oswego, New York
Dear DDJ,
Tom Swan's algorithm #0 (see DDJ, May 1993) does a fascinating job of fast approximation. However, most languages have something like sqr(x) already built in, so I tried to expand the formula to calculate cube roots. After some twiddling with exponents and factors, I got it stable and working. My version of line 6 in Tom's pseudocode is y(x/(y2)+2*y)/3.
Comparing the two formulas, it seemed to me that both of were special cases of a general algorithm to calculate the mth root of x. (Let m be 2 for sqr(), 3 for cube, and so on.) Fortunately, the solution turns out to be very simple. The formula for the mth root of x approximation is y(x/(y(m-1))+(m-1)*y)/m. Now, that's definitely something I like to have in my bags of tricks and want to thank Tom for his article.
Another interesting experience was that this algorithm quite soon delivers precise results within the accuracy of the data type, that is, double (64 bits). So it seems to make sense simply to test the y variable after each iteration. If it doesn't change, you're done and you exit the loop. A typical numerical example for m=3 and x=70,957,944 results to 414 after 34 iterations. After 28 iterations the result is still far from accurate (>426), but the last six passes lead to perfect accuracy. Consider this: For more than 80 percent of the execution time, the intermediate result is far from accurate. Any attempt to reduce execution time by one or two passes will be more than compensated by the computational overhead involved. But if you prefer to write bigger pieces of code that execute slower, please do not call that mess a function. Use the classifier "object" instead.
Gerhard Schwartzmann
Vienna, Austria
Dear DDJ,
The article "Comparing Object-oriented Languages" (DDJ, October 1993) inadvertently stated the name of our company as "Rational Systems." Rational Systems is a Massachusetts-based company that sells C compilers and DOS extenders.
The correct full name of our company is "Rational." Among the software-engineering we provide are Rational Rose, an object-oriented analysis and design tool; Rational C++ Booch Components, an object-oriented class library; and Rational Apex, a sophisticated software-engineering environment for Ada.
Kara Myers
Rational
Santa Clara, California
Dear DDJ,
Al Steven's solution to adding a satellite keypad is interesting ("C Programming," DDJ, August 1993), but I ask, "Why do it the hard way?" For an alternative approach, you might want to take a look at my tip entitled "Windows, DOS, and...Foot Pedals?" which appeared in Leor Zolman's "Tech Tips" column (Windows/DOS Developer's Journal, February 1993).
In the column, I describe how to add an "infinite" variety of satellite keypads with minimal hardware, no chips, and no software. The trick is to tap into an existing keyboard; really quite easy with the two keyboards I've mapped (the Keytronic E03435 and the Honeywell 101RXe). From that tip: Such satellite keypads need contain only switches--no chips, no software. You simply plug in the one you've chosen to the new connector on your regular keyboard. I know, it's too simple. I hear that a lot.
Homer B. Tilton
Tucson, Arizona
Dear DDJ,
I found the articles in your October 1993 issue on object-oriented languages both informative and inspiring. Your publication is the first I've read which mentions C+@, Sather, Parasol, or Beta. Although I was somewhat disappointed, however, that your coverage of these object-oriented languages didn't include Actor and Allegro. Allegro appears in an advertisement in your magazine and Actor has been popular with software developers for years.
Perhaps in a future issue you may cover the current version of Actor. Some of your readers may be interested in alternative hybrid languages such as Knowledge Garden's KnowledgePro 2.0 and StepStone's Objective-C.
I believe these software tools will become more significant when the new object-oriented operating systems become widely available: Taligent's Pink, Next's NextStep, Microsoft's Cairo, and the like.
Alton Johnson
Cromwell, Connecticut
faddxt PROC USES SI
.
.
.
DIADD2:
XOR CH, CH
ADD EAX, EBX
JNS SHORT nskludge ;modified--was DOADD3
OR DH, DH
JZ SHORT DOADD3
NEG EAX
NOT CH
JMP SHORT DOADD3 ;added
nskludge ;added
CMP DH, 2 ;added
JNE SHORT DOADD3 ;added
STC ;added
RCR EAX, 1 ;added
DEC CL ;added
NEG EAX ;added
NOT CH ;added
DOADD3:
PUSH DS
LDS BX, DWORD PTR ANSOFF
MOV [BX] .SIGN, CH
MOV [BX] .SCALE, CL
MOV [BX] .NUM, EAX
POP DS ;modified--Dr. Dobb's says POP DX
RET
faddxy ENDP
fmulxy PROC
.
.
.
MUL EBX
TSTZLP:
BSR ECX, EDX
JZ SHORT DXZ
CMP CL, 31 ;added
JB SHORT nonkludge ;added
MOV EAX, EDX ;added
SUB XARG.SCALE, 32 ;added
JUMP SHORT DXZ ;added
nokludge: ;added
INC CL
SHRD EAX, EDX, CL
SUB XARG.SCALE, CL
DXZ:
.
.
.
fmulxy ENDP
faddxy PROC USES SI
.
.
.
DOADD2:
XOR CH, CH
ADD EAX, EBX
JNS SHORT nskludge
OR DH, DH
JNZ DOADD3A
nskludge:
CMP DH,2
JNE SHORT DOADD3
STC
RCR EAX,1
DEC CL
DOADD3A:
NEG EAX
NOT CH
DOADD3:
.
.
.
POP DES ;POP DX
in origional code was incorrect
RET
.
.
.
fmulxy PROC
.
.
.
TSTZLP:
BSR ECX, EDX
JZ SHORT DXZ
CMP CL, 31
JB SHORT nokludge
MOV EAX, EDX
SUB XARG.SCALE, 32
JMP SHORT DXZ
nokludge
INC CL
Copyright © 1993, Dr. Dobb's Journal