Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!rutgers!cmcl2!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn)
Newsgroups: comp.lang.c
Subject: Re: fortran to C converter
Message-ID: <10112@smoke.BRL.MIL>
Date: 25 Apr 89 06:18:23 GMT
References: <10176@socslgw.csl.sony.JUNET> <12247@lanl.gov> <1989Apr24.172747.993@utzoo.uucp> <8050@boring.cwi.nl>
Reply-To: gwyn@brl.arpa (Doug Gwyn)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 22

In article <8050@boring.cwi.nl> dik@cwi.nl (Dik T. Winter) writes:
-In article <1989Apr24.172747.993@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes:
- > In article <12247@lanl.gov> jlg@lanl.gov (Jim Giles) writes:
- > >On the Cray, doubles have 28 digits of precision, but it takes 50 (that's
- > >right - FIFTY) time as long to compute with doubles as with singles.  That
- > >doesn't even include the fact that doubles don't vectorize!  Single precision
- > >carries 14 digits of precision and is adequate for most computation.
- > Given the pervasive nature of double in C code, sounds like Cray made a bad
- > decision (or an interim one).
-Given that Cray's choice predates C, this sounds a bit strange.  Considering
-K&R and Ansi C, I would say that K&R made a bad decision (and clearly an
-interim one).

That's completely wrong -- C predates Cray Inc. and in any case the Cray
implementor of C was free to choose either the 14-digit or the 28-digit
precision to represent C "double" type.  If Giles's description of the
relative tradeoffs is correct, then I would agree that a bad choice was
made.

In an ANSI C implementation on such a computer, the new "long double"
type would be a good match for the 28-digit precision type.  I would still
advise using the 14-digit representation for doubles.