Hi there,
the following little program
#include <stdio.h>
int main() { double d; scanf("%lf", &d); printf("%.1000g\n", d); return 0; }
does this on Linux/i686
$ gcc -W -Wall in.c $ a.out 70.9 70.900000000000005684341886080801486968994140625
and does the following under Cygwin on the same machine:
roberto@quark /tmp $ gcc -W -Wall in.c
roberto@quark /tmp $ ./a.exe 70.9 70.90000000000000568434188608080148696899414
Why? Is there a way to reconcile the two behaviors? Notice that I know about the x87 and its vaguaries: nonetheless I wonder why such a scanf immediately followed by a printf shows a difference between Cygwin and Linux. All the best,
Roberto
Roberto Bagnara wrote:
Hi there,
the following little program
#include <stdio.h>
int main() { double d; scanf("%lf", &d); printf("%.1000g\n", d); return 0; }
does this on Linux/i686
$ gcc -W -Wall in.c $ a.out 70.9 70.900000000000005684341886080801486968994140625
and does the following under Cygwin on the same machine:
roberto@quark /tmp $ gcc -W -Wall in.c
roberto@quark /tmp $ ./a.exe 70.9 70.90000000000000568434188608080148696899414
Why? Is there a way to reconcile the two behaviors? Notice that I know about the x87 and its vaguaries: nonetheless I wonder why such a scanf immediately followed by a printf shows a difference between Cygwin and Linux.
If you haven't gone out of your way to install similar printf() support libraries on cygwin and linux, they will definitely not be the same. My past reading of various relevant documents convinced me that digits beyond the 17th in formatting of doubles are not required by any standard to be consistent between implementations. They have no useful function, as 17 digits are sufficient to determine uniquely the corresponding binary value in IEEE 754 format.
Tim Prince wrote:
Roberto Bagnara wrote:
Hi there,
the following little program
#include <stdio.h>
int main() { double d; scanf("%lf", &d); printf("%.1000g\n", d); return 0; }
does this on Linux/i686
$ gcc -W -Wall in.c $ a.out 70.9 70.900000000000005684341886080801486968994140625
and does the following under Cygwin on the same machine:
roberto@quark /tmp $ gcc -W -Wall in.c
roberto@quark /tmp $ ./a.exe 70.9 70.90000000000000568434188608080148696899414
Why? Is there a way to reconcile the two behaviors? Notice that I know about the x87 and its vaguaries: nonetheless I wonder why such a scanf immediately followed by a printf shows a difference between Cygwin and Linux.
If you haven't gone out of your way to install similar printf() support libraries on cygwin and linux, they will definitely not be the same. My past reading of various relevant documents convinced me that digits beyond the 17th in formatting of doubles are not required by any standard to be consistent between implementations. They have no useful function, as 17 digits are sufficient to determine uniquely the corresponding binary value in IEEE 754 format.
Thank you Tim. We were unaware of this giant bug in the C standard. All the best,
Roberto
On Sun, 2006-03-05 at 12:44 +0100, Roberto Bagnara wrote:
Tim Prince wrote: My
past reading of various relevant documents convinced me that digits beyond the 17th in formatting of doubles are not required by any standard to be consistent between implementations. They have no useful function, as 17 digits are sufficient to determine uniquely the corresponding binary value in IEEE 754 format.
Thank you Tim. We were unaware of this giant bug in the C standard. All the best,
There is no bug in the C Standard. The C standard makes it clear the accuracy of floating point operations is implementation defined ,and the implementor may even say the accuracy is undefined.
This is not a bug, it is the proper thing for a language standard.
skaller wrote:
On Sun, 2006-03-05 at 12:44 +0100, Roberto Bagnara wrote:
Tim Prince wrote: My
past reading of various relevant documents convinced me that digits beyond the 17th in formatting of doubles are not required by any standard to be consistent between implementations. They have no useful function, as 17 digits are sufficient to determine uniquely the corresponding binary value in IEEE 754 format.
Thank you Tim. We were unaware of this giant bug in the C standard. All the best,
There is no bug in the C Standard. The C standard makes it clear the accuracy of floating point operations is implementation defined ,and the implementor may even say the accuracy is undefined.
Which operations are you talking about? I am not talking about floating point operations.
This is not a bug, it is the proper thing for a language standard.
Call it the way you want: I call `buggy' a standard that allows an invocation of
printf("%.37g\n", d);
to silently ignore 20 or so significant digits (and apparently for no good reason, by the way). You can call it `bad design', if you prefer. Or `unfortunate legacy'. You are of course free to call it `good design' if you like it. All the best,
Roberto
There was discussion last year on something similar. Even though the code bases are similar, there are differences between mingw, cygwin and linux base code at the lower levels that are beyond my area of expertise.
http://www.cygwin.com/ml/cygwin/2005-07/msg00177.html
You will probably find that your linux and cygwin use different C libraries (newlib versus glibc or others) or different versions where the lower level functions like fesetround or strtod operate differently. Some digging will probably pop out the answer.
I'm a lurker on the list so this is the limit of my help.
Larrie.
From: "Roberto Bagnara"
Hi there,
the following little program
#include <stdio.h>
int main() { double d; scanf("%lf", &d); printf("%.1000g\n", d); return 0; }
does this on Linux/i686
$ gcc -W -Wall in.c $ a.out 70.9 70.900000000000005684341886080801486968994140625
and does the following under Cygwin on the same machine:
roberto@quark /tmp $ gcc -W -Wall in.c
roberto@quark /tmp $ ./a.exe 70.9 70.90000000000000568434188608080148696899414
Why? Is there a way to reconcile the two behaviors? Notice that I know about the x87 and its vaguaries: nonetheless I wonder why such a scanf immediately followed by a printf shows a difference between Cygwin and Linux. All the best,
Roberto
Wouldn't this old discussion apply.
participants (4)
-
Larrie Carr -
Roberto Bagnara -
skaller -
Tim Prince