Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site turtlevax.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!gamma!epsilon!zeta!sabre!petrus!bellcore!decvax!decwrl!turtlevax!ken
From: ken@turtlevax.UUCP (Ken Turkowski)
Newsgroups: net.lang.c
Subject: Re: double vs single precision
Message-ID: <1020@turtlevax.UUCP>
Date: Fri, 10-Jan-86 17:59:09 EST
Article-I.D.: turtleva.1020
Posted: Fri Jan 10 17:59:09 1986
Date-Received: Mon, 13-Jan-86 08:03:30 EST
References: <1333@brl-tgr.ARPA>
Reply-To: ken@turtlevax.UUCP (Ken Turkowski)
Organization: CIMLINC, Inc. @ Menlo Park, CA
Lines: 40
Summary: K&R is wrong

In article <1333@brl-tgr.ARPA> tribble_acn%uta.csnet@csnet-relay.arpa (David Tribble) writes:
>For the last few weeks there has been on-going discussion of
>the merits and drawbacks (demerits?) of the precision the compiler
>sees fit to use for statements like-
>	float a, b;
>	a = a + 1.0;	/* 1 */
>	a = a + b;	/* 2 */
>One argument that should be mentioned is that some compiler writers
>choose the criteria-
>	1. It keeps runtime code small, because only one floating
>	   point routine ($dadd) is required; a single-precision
>	   $fadd is not necessary.

Routine?  What's wrong with using the single-word machine
instructions?  There's no reason not to use floating-point hardware
since it is now so cheap and available.

>	2. It agrees with K&R's definition of 'the usual arithmetic
>	   conversions' for doing arithmetic operations.

Just because it agrees with K&R doesn't make it right.  Nearly every
other programming language states that if you want computations to be
done at higher precision than any of the operands, then you cast any
one of them to the higher precision.

This should be done for chars and shorts as well as floats and longs.
(could cast a long to double for more precision, but not to float)

What's that?  You say it breaks existing code?  The easy solution to
that is:

#define char	long
#define short	long
#define int	long
#define float	double

-- 
Ken Turkowski @ CIMLINC, Menlo Park, CA
UUCP: {amd,decwrl,hplabs,seismo,spar}!turtlevax!ken
ARPA: turtlevax!ken@DECWRL.DEC.COM