Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10 5/3/83 based; site hou2d.UUCP Path: utzoo!decvax!bellcore!petrus!scherzo!allegra!ulysses!mhuxr!mhuxt!houxm!hou2d!osd From: osd@hou2d.UUCP (Orlando Sotomayor-Diaz) Newsgroups: mod.std.c Subject: mod.std.c Digest V10#6 Message-ID: <719@hou2d.UUCP> Date: Tue, 24-Sep-85 20:11:48 EDT Article-I.D.: hou2d.719 Posted: Tue Sep 24 20:11:48 1985 Date-Received: Thu, 26-Sep-85 03:28:45 EDT Organization: AT&T Bell Labs, Holmdel NJ Lines: 147 Approved: osd@hou2d.UUCP From: Orlando Sotomayor-Diaz (The Moderator) mod.std.c Digest Tue, 24 Sep 85 Volume 10 : Issue 6 Today's Topics: float vs double and all that Numerical conversions Order of Evaluation and Parentheses ---------------------------------------------------------------------- Date: Sat, 21 Sep 85 20:59:31 EDT From: Chris Torek Subject: float vs double and all that To: std-c@cbosgd I am responding to three articles, from gnb@mullian.oz (Greg Bond), Vincent Manis , and Niket K. Patwardhan . First, it appears that at least two of you have not read the latest ANSI X3J11 draft. If you have not, go forth now and do so. (If at all possible---I realize there can be problems.) > I vote for at least _allowing_ an implementation to use float > arithmetic. [Greg Bond] It *is* allowed in the draft standard. Also, the 4.3BSD Vax C compiler has a new flag (-f) to tell the compiler to use float where float suffices. (Thanks, Donn.) > The coercion of floats to doubles as procedure parameters is just > plain wrong, [Vincent Manis] I would not make such a broad statement. If converting a float to a double and back gives you precisely the same bit pattern every time, it cannot possibly be wrong. Say rather that the coercion is undesirable on some machines. > What I'd like is the ability to disable that coercion (perhaps by > means of a pragma). That way, if I really want floats to be floats, > I can get that behaviour. [VM] While I do not claim the method is ideal, you can already do this: just pass all ``float'' values by address. It is admittedly clumsy and error-prone. [You at least appear to have read the draft. Congratulations! :-) ] > C has even a bigger problem with floating point than the use of > double precision for all floating point calculations. Floating > point computations are not really associative and distributive, > and the fact that C will reorder such operations (EVEN IN THE > PRESENCE OF PARENTHESIS!!) means that for most numeric applications > C is quite useless. [Niket K. Patwardhan] First off, even in current C this is not a serious problem. If you intend to have ``a + b'' done first, then ``/ c'', then ``* d'', just write double a, b, c, d, result; /* or float */ result = a + b; result /= c; result *= d; You may not like it, but the compiler does, and it produces exactly that code which you would expect---unlike some FORTRAN compilers. In any case, under the proposed standard, it is even easier: result = (+((+(a + b)) / c)) * d; Not pretty perhaps, but to the point; and since parentheses are often used when not truly necessary, efficient as well. (As an aside, I might also point out that on some (many?) machines, integer arithmetic is neither associative nor distributive either. Would you have C changed not to reorder parenthesized integer expressions?) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 4251) UUCP: seismo!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@maryland ------------------------------ Date: Sat, 21 Sep 85 17:14:00 edt From: cbnap!whp Subject: Numerical conversions To: std-c@cbosgd I have read the comments on float to double conversion; I wonder if many people are aware that conversion is done on types char and short too? That is, variables of type char or type short are converted to int before any arithmetic operatons, and when passed as an argument to a function or returned from a function (just like floats are converted to doubles). Perhaps a consistant approach for chars, shorts, and floats should be used. Wayne Pollock, {ihnp4, cbosgd}!cbnap!whp ------------------------------ Date: 22 Sep 1985 22:13:41-EDT (Sunday) From: "Josh Knight" Subject: Order of Evaluation and Parentheses To: std-c@cbosgd In mod.std.c Digest, V. 10, Issue 4, Niket K. Patwardhan complains that the fact that parentheses do not insure *any* order of evaluation in C makes the language useless for numerical analysis purposes. I think that one should be **VERY** explicit in any code where the order of evaluation makes a difference, and assigning a variable to a temporary explicitly probably isn't too costly. The example given: > > sum = a + b + c + d + e + large > Can be fixed with small = a + b + c + d + e ; /* this must be evaluated first */ sum = small + large ; /* to avoid loss of precision */ As well as (and more clearly than) the proposed sum = (a + b + c + d + e) + large ; and in any event the ANSI draft standard provides a way to insure evaluation order without assigning to temporary variables: the unary plus. If one likes the terser version, then sum = +(a + b + c + d + e) + large ; should produce the desired order of evaluation with a C compiler conforming to the standard. Anybody got one (:-)? Of course, any opinions, expressed or implied are mine and not my employers... Josh Knight IBM T.J. Watson Research Center josh@yktvmh.BITNET, josh.yktvmh.ibm-sj@csnet-relay.ARPA ------------------------------ End of mod.std.c Digest - Tue, 24 Sep 85 20:10:46 EDT ****************************** USENET -> posting only through cbosgd!std-c. ARPA -> ... through cbosgd!std-c@BERKELEY.ARPA (NOT to INFO-C) In all cases, you may also reply to the author(s) above. Brought to you by Super Global Mega Corp .com