Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!dogie.macc.wisc.edu!uwvax!rutgers!cmcl2!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn)
Newsgroups: comp.lang.c
Subject: Re: fortran to C converter
Message-ID: <10121@smoke.BRL.MIL>
Date: 26 Apr 89 06:17:14 GMT
References: <12787@haddock.ima.isc.com> <12661@lanl.gov>
Reply-To: gwyn@brl.arpa (Doug Gwyn)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 42

In article <12661@lanl.gov> jlg@lanl.gov (Jim Giles) writes:
>By the way, what _is_ "long double"?  I've never seen a C compiler which
>has such a thing.

We could have guessed that from the tone of your earlier remarks.

>The proposed ANSI standard mentions "long double", but doesn't require
>it to be more precise than double!

That's correct; it doesn't require double to be more precise than float,
either, although the MINIMUM number of digits of significance REQUIRED
for both double and long double is greater than for float, and each
"larger" type is required to be able to express a (not necessarily
proper) superset of the values of the "smaller" types.  The exact
rationale for the particular requirements of the Standard is fairly
lengthy, but basically the Standard guarantees what was considered to
be minimum acceptable accuracy without forcing too many implementations
into software emulation.  Implementations that have hardware support
for very long floating-point are advised to map long double onto that,
but so long as the requirements of the Standard are met, such details
are a matter of quality of implementation and are therefore left up to
the marketplace to determine.

>In fact, the only surprising thing about floating point in the standard
>is that it requires the FLT_RADIX to be 2 - that is, it requires "float"
>to be binary!  No radix is defined for "double" or "long double".

You cannot have read the Standard very carefully.  FLT_RADIX applies
to all three floating types.  Also, FLT_RADIX is required to be AT LEAST
2, not PRECISELY 2.  Furthermore, the implementation does not have to
adhere exactly to the particular (Fortran-inspired) model used in Section
2.2.4.2 of the Standard; for example, it could use variable-width
encodings.  The minima required for Standard conformance are to be
taken in strict accordance with the given model, and the implementation
definition of the macros upon inclusion of <float.h> is intended to be
a guarantee of minimum precision, etc.; however, the implementation is
allowed to be arbitrarily better than described by <float.h>.  It is in
an implementor's best interests to make his <float.h> indicate as much
guaranteed precision and exponent range as is feasible.

P.S.  This is not an official X3J11 interpretation.  For that, send a
query to X3J11 via CBEMA X3.