Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!ll-xn!ames!oliveb!sun!gorodish!guy
From: guy%gorodish@Sun.COM (Guy Harris)
Newsgroups: comp.lang.c
Subject: Re: Order of evaluation, machine floating point
Message-ID: <14632@sun.uucp>
Date: Fri, 6-Mar-87 17:18:41 EST
Article-I.D.: sun.14632
Posted: Fri Mar  6 17:18:41 1987
Date-Received: Sun, 8-Mar-87 12:09:21 EST
References: <4775@brl-adm.ARPA>
Sender: news@sun.uucp
Lines: 42

> C (as presented to me by its compilers on Pyramids, Suns, and Vaxes) is
> NOT terribly strong on floating point arithmetic,

To be fair, the primary intent of C was not to support floating-point
computation; that's probably why many C compilers don't devote a lot
of effort to doing a good job with it.

> first, for unknown reasons all floating arithmetic is supposed to occur
> in double precision.  I realize that K&R said it, but I don't know why.

I don't know either.  I think one reason why the PDP-11 C compiler
did so was that it took some extra work to use the instructions to
switch between single-precision and double-precision mode on the
PDP-11's floating point coprocessor (and to make sure the mode was
properly maintained across procedure calls, etc.) and they didn't use
floating point enough to feel it was worth it.  Some other arguments
have been given (which I don't remember the details of offhand), but
given that a number of people knowledgable about floating-point
computation have complained about this aspect of C, I don't know that
those arguments were necessarily valid.

Even given the above, it's not clear to me why K&R *mandated* that
floating-point computations be done in double-precision; it may have
wanted to *permit* that to be done, but I don't see why it should
have *required* it.  The ANSI C committee has fixed this; it is no
longer required to perform all floating-point computations in
double-precision, although it is permitted.  If function prototypes
are used, float-to-double conversions are not performed either unless
the formal argument is declared as "double".  I see no discussion
that indicates the behavior of a function declared to return "float",
but I assume that an implementation is permitted not to treat that as
"really" returning "double".

> Second, several compilers have exhibited bugs compiling "a += b" when a
> and b are floats.  For some reason, these compilers decide to perform
> THAT addition in single precision.  Someone had to work hard to add that
> bug to the compiler; if "a += b" is the same as "a = a + b",

Inside PCC (upon which I believe at least some of the compilers in
question are based), "a += b" *isn't* the same as "a = a + b"; it
knows that there is an "add to" operator distinct from the "add"
operator.