Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site brl-tgr.ARPA
Path: utzoo!watmath!clyde!cbosgd!ihnp4!qantel!lll-crg!seismo!brl-tgr!gwyn
From: gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>)
Newsgroups: net.lang.c
Subject: Re:  C Floating point arithmetic
Message-ID: <168@brl-tgr.ARPA>
Date: Fri, 29-Nov-85 03:28:11 EST
Article-I.D.: brl-tgr.168
Posted: Fri Nov 29 03:28:11 1985
Date-Received: Sat, 30-Nov-85 06:49:51 EST
References: <123@brl-tgr.ARPA> <1078@lll-crg.ARpA>
Organization: Ballistic Research Lab
Lines: 23

> >I am in favor of supporting low-precision floating point in
> >C, as permitted by X3J11, but let's not make it the default.
> 
> This argument is hard to swallow. You are suggesting protection
> for the user by not giving him what he has asked for in his
> code.

That was NOT what I said.  "I am in favor of supporting
low-precision floating-point in C, as permitted by X3J11."

This means that the compiler is free to evaluate
	(float) op (float)
in single-precision if the implementer decides to do so.
The implementer may choose instead to continue to coerce
(float)s to (double)s in expressions.  Presumably most C
implementations, especially those on number crunchers,
would support single-precision operations.

For compatibility reasons, if none other, it is essential
to maintain (double)-ness for floating-point constants etc.
One can obtain single-precision by something like
	(float)1.0
if so inclined.