osd@hou2d.UUCP (Orlando Sotomayor-Diaz) (09/25/85)
From: Orlando Sotomayor-Diaz (The Moderator) <cbosgd!std-c>
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 <seismo!umcp-cs!chris>
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 <manis@cs.ubc.cdn>, and Niket K. Patwardhan
<lcc.niket@LOCUS.UCLA.EDU>.
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" <psuvax1!JOSH@YKTVMH.BITNET>
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.