[mod.std.c] mod.std.c Digest V10#4

osd@hou2d.UUCP (Orlando Sotomayor-Diaz) (09/21/85)

From: Orlando Sotomayor-Diaz (The Moderator) <cbosgd!std-c>


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 <manis@cs.ubc.cdn>
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" <lcc.niket@LOCUS.UCLA.EDU>
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.