lcw1964 said:
I have recompiled some old math code that uses long double types
throughout and provides the corresponding range and precision (up to 18
digits, with exponents up to about -/+ 4900) when compiled under an
older version of BC++.
You're making an assumption about the correct range and precision of
long double.
In the MinGW incarnation of gcc, I have made a couple of adjustments to
get it to compile--in particular, _atold() doesn't exist, and atof() is
prototyped only in stdlib.h whereas in BC++ it is listed in math.h too.
MinGW is correct about atof(); according to the standard, it's
not in <math.h>. _atold() is non-standard said:
However, I kept all of my long double declarations and outputs as that,
and used all of the long double versions of the math functions--expl(),
fabsl(), etc. The file complied but the output was gibberish. It took a
little googling to find that I had to recast the long double output as
double so printf() could meaningfully display it.
No, you just have to use the correct format. Use "%e", "%g", or "%f"
for float or double (float is promoted to double in a call to
printf()); use "%Le", "Lg", or "%Lf" for long double.
However, I have come to suspect that MinGW's long double isn't really
long double, and that somewhere in the process the range and precision
of of the floating point math has been restricted to the double range.
For example, in the original code under BC++ (not MSVC++, which is well
known to recast everything as double) I can generate a meaningful
answer of, say 1.34598900000098888e-2345, whereas the MinGW compiled
version will render this tiny value as simply 0.
C defines three floating-point types: float, double, and long double.
The standard requires float to have a precision of at least 6 decimal
digits; double and long double require at least 10. The maximum
representable value for all three types is required to be at least
1E+37.
There's no requirement for long double to be bigger than double; they
could have exactly the same representation (just as short and int or
int and long often have the same representation). The type "long
double" exists to *allow* an implementation to provide a large type,
not to require it.
My question is this--does MinGW offer the "true" long double floating
point 80bit type, and if so how can I get my programs to display
results of the sort I mentioned in the previous paragraph is printf()
needs recasting to double in order to handle it?
I don't know whether MinGW offers a long double type bigger than
double, though the fact that you had trouble printing long double
values makes me suspect that it does.
Try compiling and executing this program:
#include <float.h>
#include <limits.h>
#include <stdio.h>
int main(void)
{
printf("float is %d bits\n", CHAR_BIT * (int)sizeof(float));
printf("double is %d bits\n", CHAR_BIT * (int)sizeof(double));
printf("long double is %d bits\n", CHAR_BIT * (int)sizeof(long double));
printf("\n");
printf("FLT_DIG = %d\n", FLT_DIG);
printf("DBL_DIG = %d\n", DBL_DIG);
printf("LDBL_DIG = %d\n", LDBL_DIG);
printf("\n");
printf("FLT_MIN = %g\n", FLT_MIN);
printf("DBL_MIN = %g\n", DBL_MIN);
printf("LDBL_MIN = %Lg\n", LDBL_MIN);
printf("\n");
printf("FLT_MAX = %g\n", FLT_MAX);
printf("DBL_MAX = %g\n", DBL_MAX);
printf("LDBL_MAX = %Lg\n", LDBL_MAX);
return 0;
}
Note that the number of bits doesn't necessarily mean that all those
bits are used; you might have a 96-bit long double of which only 80
bits are actually used.
There's another potential problem. An implementation consists of two
parts, the compiler and the runtime library (plus the linker and
perhaps a few other things). Very often the runtime library is
provided as part of the operating system, and the compiler is provided
by a third party, so they might not be in sync. If your compiler
assumes that long double has one representation, and your runtime
library's implementation of printf() assumes a different
representation, you're going to have problems. In that case, you have
a non-conforming (broken) implementation -- and there might not be
much you can do about it.
