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!watmath!clyde!burl!ulysses!mhuxr!mhuxn!ihnp4!houxm!hou2d!osd From: osd@hou2d.UUCP (Orlando Sotomayor-Diaz) Newsgroups: mod.std.c Subject: mod.std.c Digest V10#4 Message-ID: <711@hou2d.UUCP> Date: Fri, 20-Sep-85 20:17:13 EDT Article-I.D.: hou2d.711 Posted: Fri Sep 20 20:17:13 1985 Date-Received: Sun, 22-Sep-85 06:26:26 EDT Organization: AT&T Bell Labs, Holmdel NJ Lines: 92 Approved: osd@hou2d.UUCP From: Orlando Sotomayor-Diaz (The Moderator) mod.std.c Digest Fri, 20 Sep 85 Volume 10 : Issue 4 Today's Topics: float vs double (3 msgs) ---------------------------------------------------------------------- Date: Thu, 19 Sep 85 10:21:50 est From: gnb@mullian.oz (Greg Bond) Subject: float vs double To: On Gould UTX systems (a 4.2BSD derivative), arithmetic on floats is done in single precision, unless: 1) One argument is a double (the other argument is converted), or 2) The expression is a parameter to a function (in which case the result is converted to a double). To quote the manual, ``This was done to increase performance''. Because all arguments are doubles, there is only one maths library etc, and users never notice the difference. On a Gould, a mulf is ~4x faster than a muld, and, since doubles can't be kept in register variables, register floats are nearly 5x faster than doubles. Certainly a worthwhile improvement.... I vote for at least _allowing_ an implementation to use float arithmetic. Gregory Bond (gnb@mullian.ee.mu.oz), Electrical Engineering, Melbourne Uni VOICE: (03) 344 7436 or Yell, very loudly... Unix systems-type for hire... Has Gould experience... ------------------------------ Date: Tue, 17 Sep 85 19:54:55 pdt From: Vincent Manis Subject: float vs double To: microsoft!decvax!cbosgd!std-c The coercion of floats to doubles as procedure parameters is just plain wrong, regardless of whether it makes programs more or less efficient. I'm not a numerical analyst (I consider reals somewhat infra dig, to be truthful), but I do know that tight control of precision is rather necessary in order to predict errors. In particular, the present C standard makes it fairly difficult to test a program in single vs double precision. 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. There would be no stated advantage in efficiency to either method. (Some machines would probably prefer doubles, but most would probably prefer floats.) ------------------------------ Date: Thu, 19 Sep 85 11:01:43 PDT From: "Niket K. Patwardhan" Subject: float vs double To: cbosgd!std-c@LOCAL.Berkeley.EDU 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. To give an example of what reordering can do in floating point computations, look at the following:- sum = a + b + c + d + e + large where a-e are .2, large is 1.0, and the precision of the machine is 1 digit. If large is introduced into the computation anywhere other than last, you get 1.0 as the result, but done unreordered you get 2.0. If there are negative and positive quantities present, things can get real bad. with relative errors (error / correct value) going all the way upto infinity! This is not quite as academic as it may seem, for in many practical cases it is known (a priori) that certain variables in a computation will be much larger than others. As a result (and because C lacks the vast library of math functions available for FORTRAN) I would never use C for numeric applications, even though I am a great fan of it for other uses. Maybe the standards committee will reconsider the parenthesis decision, or at least define + and * as not associative when applied to floating point numbers. Brodie & Plum -- are you listening? ------------------------------ End of mod.std.c Digest - Fri, 20 Sep 85 20:11:09 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