From: Sternbach, William [IT] <william.sternbach@ci...>  20020919 12:50:18

> Greg, > > Thank you for solving that gcc 3.2 pecision problem. > > I hope its ok if I ask you a few brief questions: > > 1) Is 0x037f the maximum floating point precision I can set. > > 2) What is the maximum # of digits to the left of the decimal point > that I can get with regular C? > > 3) Does GCC 3.1, 3.2 support the "long double" data type? > > > I write alot of mathematical number crunching programs, and your > answers to these questions will help me alot. > > Thanks in advance for your Email reply. > >  Bill 
From: Sternbach, William [IT] <william.sternbach@ci...>  20020919 12:50:18

> Greg, > > Thank you for solving that gcc 3.2 pecision problem. > > I hope its ok if I ask you a few brief questions: > > 1) Is 0x037f the maximum floating point precision I can set. > > 2) What is the maximum # of digits to the left of the decimal point > that I can get with regular C? > > 3) Does GCC 3.1, 3.2 support the "long double" data type? > > > I write alot of mathematical number crunching programs, and your > answers to these questions will help me alot. > > Thanks in advance for your Email reply. > >  Bill 
From: Sternbach, William [IT] <william.sternbach@ci...>  20020920 13:07:29

Greg, Please give me more detail on how I can use an 80 digit mantissa with gcc 3.2. Whenever I use printf to display a double, I only get 17 digits of precision to the left of the decimal point. Please see: 1) The program source code (below). 2) Compiler warnings about the numbers being too big. 3) Erroneous output of the program. Please Email me with your comments. Thanks in advance for your help, Bill   1) The Program source code. #include <stdio.h> int main() { double fp_accum; double fp_i; long double LD_fp_accum; long double LD_fp_i; fp_accum = 0; for (fp_i = 111222333444555666777888999000.1234567890 ;fp_i < 111222333444555666777888999999; ++fp_i) { fp_accum = fp_accum + (fp_i * fp_i); } printf("Floating point running total = %lf\n\n", fp_accum); LD_fp_accum = 0; for (LD_fp_i = 111222333444555666777888999000.1234567890; LD_fp_i < 111222333444555666777888999999; ++LD_fp_i) { LD_fp_accum = LD_fp_accum + (LD_fp_i * LD_fp_i); } printf("Floating point running total = %Lf\n", LD_fp_accum); return 0; }  2) Compiler warnings about the numbers being too big. M:\PROGRAMS\MISC>gcc O9 fptest4.c ofptest4.exe fptest4.c: In function `main': fptest4.c:10: warning: integer constant is too large for this configuration of t he compiler  truncated to 64 bits fptest4.c:16: warning: integer constant is too large for this configuration of t he compiler  truncated to 64 bits  3) Erroneous output of the program. M:\PROGRAMS\MISC>fptest4 Floating point running total = 0.000000 Floating point running total = 0.000000  Bill Original Message From: Greg Chicares [mailto:chicares@...] Sent: Friday, September 20, 2002 1:08 AM To: Sternbach, William [IT]; 'MinGWusers@...' Subject: Re: [Mingwusers] Gcc 3.2 floating point precision. "Sternbach, William [IT]" wrote: > > > Thank you for solving that gcc 3.2 pecision problem. > > > > I hope its ok if I ask you a few brief questions: > > > > 1) Is 0x037f the maximum floating point precision I can set. Yes. Actually only the two bits corresponding to the '3' affect the precision. With both bits set to 1, you get the maximum precision the hardware offers. The other bits control things like rounding and exceptions. > > 2) What is the maximum # of digits to the left of the decimal point > > that I can get with regular C? Lots. With the intel architecture, a little over 300 with double, and almost 5000 with long double. Of course, only the first few are significant. #include <float.h> #include <stdio.h> int main() { printf("%f\n", DBL_MAX); return 0; } 1797693134862315700000000000000000000000000000000000000000000000000000000000 0000 0000000000000000000000000000000000000000000000000000000000000000000000000000 0000 0000000000000000000000000000000000000000000000000000000000000000000000000000 0000 000000000000000000000000000000000000000000000000000000000000000000000.000000 I'd print LDBL_MAX here, but the msvc runtime library doesn't support 80bit long double, and this email is too small to contain it anyway. > > 3) Does GCC 3.1, 3.2 support the "long double" data type? Yes. > > I write alot of mathematical number crunching programs, and your > > answers to these questions will help me alot. > > > > Thanks in advance for your Email reply. 
From: Mikael Aronsson <mikaelaronsson@te...>  20020920 13:12:55

Hi ! You have to be a bit careful, you can use 80 bit floating point values with gcc, but the msvcrt runtime can only handle 32 and 64 bit floating point values, so printf,scanf and so on will not work with 80 bit values. Mikael  Original Message  From: "Sternbach, William [IT]" <william.sternbach@...> To: "'Greg Chicares'" <chicares@...> Cc: <mingwusers@...> Sent: Friday, September 20, 2002 2:04 PM Subject: [Mingwusers] Gcc 3.2 floating point precision. > Greg, > > Please give me more detail on how I can use an 80 digit > mantissa with gcc 3.2. > > Whenever I use printf to display a double, I only get > 17 digits of precision to the left of the decimal point. > > Please see: > 1) The program source code (below). > 2) Compiler warnings about the numbers being too big. > 3) Erroneous output of the program. > > Please Email me with your comments. > > Thanks in advance for your help, > > Bill >   >  > > 1) The Program source code. > > #include <stdio.h> > int main() > { > double fp_accum; > double fp_i; > long double LD_fp_accum; > long double LD_fp_i; > > fp_accum = 0; > for (fp_i = 111222333444555666777888999000.1234567890 ;fp_i < > 111222333444555666777888999999; ++fp_i) { > fp_accum = fp_accum + (fp_i * fp_i); > } > printf("Floating point running total = %lf\n\n", fp_accum); > > LD_fp_accum = 0; > for (LD_fp_i = 111222333444555666777888999000.1234567890; LD_fp_i < > 111222333444555666777888999999; ++LD_fp_i) { > LD_fp_accum = LD_fp_accum + (LD_fp_i * LD_fp_i); > } > printf("Floating point running total = %Lf\n", LD_fp_accum); > return 0; > } > >  > > 2) Compiler warnings about the numbers being too big. > > M:\PROGRAMS\MISC>gcc O9 fptest4.c ofptest4.exe > fptest4.c: In function `main': > fptest4.c:10: warning: integer constant is too large for this configuration > of t > he compiler  truncated to 64 bits > fptest4.c:16: warning: integer constant is too large for this configuration > of t > he compiler  truncated to 64 bits > >  > > 3) Erroneous output of the program. > > M:\PROGRAMS\MISC>fptest4 > Floating point running total = 0.000000 > > Floating point running total = 0.000000 > > >  Bill > > > Original Message > From: Greg Chicares [mailto:chicares@...] > Sent: Friday, September 20, 2002 1:08 AM > To: Sternbach, William [IT]; 'MinGWusers@...' > Subject: Re: [Mingwusers] Gcc 3.2 floating point precision. > > > "Sternbach, William [IT]" wrote: > > > > > Thank you for solving that gcc 3.2 pecision problem. > > > > > > I hope its ok if I ask you a few brief questions: > > > > > > 1) Is 0x037f the maximum floating point precision I can set. > > Yes. Actually only the two bits corresponding to the '3' > affect the precision. With both bits set to 1, you get > the maximum precision the hardware offers. The other > bits control things like rounding and exceptions. > > > > 2) What is the maximum # of digits to the left of the decimal point > > > that I can get with regular C? > > Lots. With the intel architecture, a little over 300 > with double, and almost 5000 with long double. Of > course, only the first few are significant. > > #include <float.h> > #include <stdio.h> > > int main() > { > printf("%f\n", DBL_MAX); > return 0; > } > > 1797693134862315700000000000000000000000000000000000000000000000000000000000 > 0000 > 0000000000000000000000000000000000000000000000000000000000000000000000000000 > 0000 > 0000000000000000000000000000000000000000000000000000000000000000000000000000 > 0000 > 000000000000000000000000000000000000000000000000000000000000000000000.000000 > > I'd print LDBL_MAX here, but the msvc runtime library > doesn't support 80bit long double, and this email is > too small to contain it anyway. > > > > 3) Does GCC 3.1, 3.2 support the "long double" data type? > > Yes. > > > > I write alot of mathematical number crunching programs, and your > > > answers to these questions will help me alot. > > > > > > Thanks in advance for your Email reply. > > >  > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > MinGWusers mailing list > MinGWusers@... > > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingwusers > 
From: Greg Chicares <chicares@mi...>  20020920 05:08:34

"Sternbach, William [IT]" wrote: > > > Thank you for solving that gcc 3.2 pecision problem. > > > > I hope its ok if I ask you a few brief questions: > > > > 1) Is 0x037f the maximum floating point precision I can set. Yes. Actually only the two bits corresponding to the '3' affect the precision. With both bits set to 1, you get the maximum precision the hardware offers. The other bits control things like rounding and exceptions. > > 2) What is the maximum # of digits to the left of the decimal point > > that I can get with regular C? Lots. With the intel architecture, a little over 300 with double, and almost 5000 with long double. Of course, only the first few are significant. #include <float.h> #include <stdio.h> int main() { printf("%f\n", DBL_MAX); return 0; } 17976931348623157000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000000000000000000.000000 I'd print LDBL_MAX here, but the msvc runtime library doesn't support 80bit long double, and this email is too small to contain it anyway. > > 3) Does GCC 3.1, 3.2 support the "long double" data type? Yes. > > I write alot of mathematical number crunching programs, and your > > answers to these questions will help me alot. > > > > Thanks in advance for your Email reply. 