Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!brl-adm!brl-smoke!gwyn From: gwyn@brl-smoke.UUCP Newsgroups: comp.lang.c Subject: Re: C and Floating Point Message-ID: <5716@brl-smoke.ARPA> Date: Wed, 1-Apr-87 18:49:44 EST Article-I.D.: brl-smok.5716 Posted: Wed Apr 1 18:49:44 1987 Date-Received: Sat, 4-Apr-87 11:10:36 EST References: <15958@sun.uucp> Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) ) Organization: Ballistic Research Lab (BRL), APG, MD. Lines: 72 Keywords: C Fortran Floating Point In article <15958@sun.uucp> dgh@sun.uucp (David Hough) writes: >After reading part way through too many postings which turn out >to be another instance of the blind arguing with the ignorant, >... I really have to take objection to the implication that people who disagree with Mr. Hough's viewpoint do so because of ignorance. It is certainly true that only a few members of X3J11 feel really comfortable concerning requirements for floating-point algorithms. However, there ARE members who do have lots of experience in this area. It is BECAUSE I care about good floating-point algorithms that I even bothered to suggest that floating-point == was not a good idea. I'm not going to try to get this put in the standard, but I WAS hoping that people like Mr. Hough might learn something from the ensuing discussion. >Fortran was created before the phrase "computer science" was imagined, >by people who were trained as applied mathematicians. Consequently they had >some familiarity with what was needed and what had been done by >mathematicians over the past several centuries. >... It is the failure to understand that the properties of machine floating-point arithmetic are NOT identical with those of the real number system of mathematics that leads to many problems in computational algorithms. The whole field of numerical analysis developed BECAUSE of initial problems encountered by programmers in the "good old days". It might be "nice" if programming languages accurately mimicked pure arithmetic, but use of hardware floating- point is simply not that pure. Wishful thinking is irrelevant here! It is totally bogus to argue that mathematicians' idea of the meaning of parentheses in expressions has anything to do with time order of evaluation. That is a Fortran notion. C actually conforms more closely to what a mathematician means by parentheses, which is to group subexpressions in order to override default rules of operator precedence. Because C also has a heavily-used macro expansion facility, we have to take that into account when deciding what the "right" thing to do with parentheses is. I assure you that X3J11 has heard the arguments that the Fortran-style proponents give, and we decided differently for SOUND REASONS. We ALSO found that their legitimate concern could be met by use of the unary + operator, which was originally introduced for unrelated reasons. Therefore there is no reason remaining other than "to act just like Fortran" that can be given for what Mr. Hough apparently would prefer. Since programmers who try to apply their Fortran intuition to C are likely to get into big trouble in many other ways (e.g. function parameters), that is a pretty weak reason. I am still waiting for a really good reason for using floating-point == in any robust algorithm. I have posted the only one that anyone has yet come up with (== 0.0 special case switch) and have also posted an example of the problems its general use can cause. I have many years of experience in programming significant numerical applications in both Fortran and C, and I am convinced that floating == is virtually NEVER a good thing to write in one's code. It would be a Very Good Thing in my estimation if "lint" (or your local equivalent) would warn about any use of floating ==, so you would be likely to re-think those sections of code. Finally, I would urge newsgroup readers to (a) consider that others may have something useful to say, and if you think you disagree, try at least to understand what their reasons are for their differing opinions, and to (b) avoid posting when you really are unlikely to contribute significantly to the discussion. Following these principles will help to reduce the volume of flamage and wasted time. (Many former useful newsgroup contributors "dropped out" long ago when they found the signal-to-noise ratio too low.) Yours for good ideas and useful discussions, Gwyn@BRL.ARPA