470,810 Members | 1,407 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 470,810 developers. It's quick & easy.

single x double precision on 32bit arch

Hi folks

I wrote the naive program to show up the unit roundoff (machine
precision) for single and double precision:

#include <stdio.h>

int main (void)
{
double x;
float y ;

x=1;
while ( (1+x) > 1 ) x = x/2;
x = 2*x;
printf("double precision epsilon: %e\n", x);

y=1;
while ( (1+y) > 1 ) y = y/2;
y = 2*y;
printf("single precision epsilon: %e\n", y);

return 0;
}

It was compiled with:
gcc -O0 epsilon.c -o epsilon

Take a look at the output on AMD64:

double precision epsilon: 2.220446e-16
single precision epsilon: 1.192093e-07

However on an Petium IV (32bit):

double precision epsilon: 1.084202e-19
single precision epsilon: 1.084202e-19

Other 32bit processors behave as pentium IV,

Am I missing something? Can anyone explain me what is going on?

Thanks.

Regards,
R. Biloti.

May 19 '06 #1
6 5490

"R.Biloti" <bi****@gmail.com> wrote in message
news:11**********************@j33g2000cwa.googlegr oups.com...
Hi folks

I wrote the naive program to show up the unit roundoff (machine
precision) for single and double precision:
[...]
Am I missing something? Can anyone explain me what is going on?


http://docs.sun.com/source/806-3568/ncg_goldberg.html

-Mike
May 19 '06 #2
R.Biloti wrote:
Hi folks

I wrote the naive program to show up the unit roundoff (machine
precision) for single and double precision:

#include <stdio.h>

int main (void)
{
double x;
float y ;

x=1;
while ( (1+x) > 1 ) x = x/2;
x = 2*x;
printf("double precision epsilon: %e\n", x);

y=1;
while ( (1+y) > 1 ) y = y/2;
y = 2*y;
printf("single precision epsilon: %e\n", y);

return 0;
}

It was compiled with:
gcc -O0 epsilon.c -o epsilon

Take a look at the output on AMD64:

double precision epsilon: 2.220446e-16
single precision epsilon: 1.192093e-07

However on an Petium IV (32bit):

double precision epsilon: 1.084202e-19
single precision epsilon: 1.084202e-19

Other 32bit processors behave as pentium IV,

Am I missing something? Can anyone explain me what is going on?

Thanks.

Regards,
R. Biloti.


I expect the compilers on the Pentia are using internal 80-bit
precision (which gives 64*log(2) ~ 19 significant decimal digits)
vs. the compiler for the AMD that probably uses the IEEE 64-bit
double and IEEE 32-bit single representations. These have, res-
pectively, about 16 and 7 significant decimal digits of pre-
cision.

--
Julian V. Noble
Professor Emeritus of Physics
University of Virginia
May 19 '06 #3
R.Biloti wrote:
Hi folks

I wrote the naive program to show up the unit roundoff (machine
precision) for single and double precision:

#include <stdio.h>

int main (void)
{
double x;
float y ;

x=1;
while ( (1+x) > 1 ) x = x/2;
x = 2*x;
printf("double precision epsilon: %e\n", x);

y=1;
while ( (1+y) > 1 ) y = y/2;
y = 2*y;
printf("single precision epsilon: %e\n", y);

return 0;
}

It was compiled with:
gcc -O0 epsilon.c -o epsilon

Take a look at the output on AMD64:

double precision epsilon: 2.220446e-16
single precision epsilon: 1.192093e-07

However on an Petium IV (32bit):

double precision epsilon: 1.084202e-19
single precision epsilon: 1.084202e-19

Other 32bit processors behave as pentium IV,

Am I missing something? Can anyone explain me what is going on?


At the risk of seeming to muddy the waters rather than clear them, I
have expanded your code below. If you run your test with it, you may
find that the results of the loops with the direct comparisons like
if (1 + y > 1) { /* ... */ }
give different results from those with a delayed comparison, like
yp = 1 + y;
if (yp > 1) { /* ... */ }
Think about why this might be so.

#include <stdio.h>
#include <float.h>

int main(void)
{
double x, xp;
float y, yp;
long double z, zp;

for (y = 1; 1 + y > 1; y /= 2) ;
printf("float epsilon: %e\n"
"FLT_EPSILON = %e\n", 2 * y, FLT_EPSILON);
for (y = 1, yp = 1 + y; yp > 1; y /= 2, yp = 1 + y) ;
printf("float epsilon (using temp): %e\n\n", 2 * y);
for (x = 1; 1 + x > 1; x /= 2) ;
printf("double epsilon: %e\n"
"DBL_EPSILON = %e\n", 2 * x, DBL_EPSILON);
for (x = 1, xp = 1 + x; xp > 1; x /= 2, xp = 1 + x) ;
printf("double epsilon (using temp): %e\n\n", 2 * x);

for (z = 1; 1 + z > 1; z /= 2) ;
printf("long double epsilon: %Le\n"
"LDBL_EPSILON = %Le\n", 2 * z, LDBL_EPSILON);
for (z = 1, zp = 1 + z; zp > 1; z /= 2, zp = 1 + z) ;
printf("long double epsilon (using temp): %Le\n\n", 2 * z);

return 0;
}
May 19 '06 #4
R.Biloti <bi****@gmail.com> wrote:

float y;
y=1;
while ( (1+y) > 1 ) y = y/2;
y = 2*y;
printf("single precision epsilon: %e\n", y);


The problem is that C allows intermediate results to have greater
precision (and/or range) than their type would imply. So, even though
(1+y) has type float, it can have the precision of double, long double,
or even more. The C Standard requires that a cast or assignment discard
any excess presision or range, so you could use either:

while ( (float)(1+y) > 1 ) y = y/2;

or

while ( y2 = 1 + y, y2 > 1 ) y = y/2;

Unfortunately, many otherwise excellent compilers do not conform to that
requirement. Most require at least an assignment, some require the
assignment to be a separate statement, and few go so far as to require
the target of the assignment to be declared volatile.

-Larry Jones

Whatever it is, it's driving me crazy! -- Calvin
May 19 '06 #5
R.Biloti wrote:
Hi folks

I wrote the naive program to show up the unit roundoff (machine
precision) for single and double precision:

#include <stdio.h>

int main (void)
{
double x;
float y ;

x=1;
while ( (1+x) > 1 ) x = x/2;
x = 2*x;
printf("double precision epsilon: %e\n", x);

y=1;
while ( (1+y) > 1 ) y = y/2;
y = 2*y;
printf("single precision epsilon: %e\n", y);

return 0;
}

It was compiled with:
gcc -O0 epsilon.c -o epsilon

Take a look at the output on AMD64:

double precision epsilon: 2.220446e-16
single precision epsilon: 1.192093e-07

However on an Petium IV (32bit):

double precision epsilon: 1.084202e-19
single precision epsilon: 1.084202e-19

Other 32bit processors behave as pentium IV,

Am I missing something? Can anyone explain me what is going on?

Thanks.

Regards,
R. Biloti.


I take it to mean
compiled and run on AMD64 system produces this result:
double precision epsilon: 2.220446e-16
single precision epsilon: 1.192093e-07
and
compiled and run on a P4 system produces this result:
Which AMD processor?
Can you describe in detail each system? (cpu, mobo, chipset, ram)
Was gcc the same version on each system? What version was it?
Thanks
Eric

May 19 '06 #6
Eric wrote:
R.Biloti wrote:
Hi folks

I wrote the naive program to show up the unit roundoff (machine
precision) for single and double precision:

#include <stdio.h>

int main (void)
{
double x;
float y ;

x=1;
while ( (1+x) > 1 ) x = x/2;
x = 2*x;
printf("double precision epsilon: %e\n", x);

y=1;
while ( (1+y) > 1 ) y = y/2;
y = 2*y;
printf("single precision epsilon: %e\n", y);

return 0;
}

It was compiled with:
gcc -O0 epsilon.c -o epsilon

Take a look at the output on AMD64:

double precision epsilon: 2.220446e-16
single precision epsilon: 1.192093e-07

However on an Petium IV (32bit):

double precision epsilon: 1.084202e-19
single precision epsilon: 1.084202e-19

Other 32bit processors behave as pentium IV,

Am I missing something? Can anyone explain me what is going on?

Thanks.

Regards,
R. Biloti.


I take it to mean
compiled and run on AMD64 system produces this result:
double precision epsilon: 2.220446e-16
single precision epsilon: 1.192093e-07
and
compiled and run on a P4 system produces this result:
Which AMD processor?
Can you describe in detail each system? (cpu, mobo, chipset, ram)
Was gcc the same version on each system? What version was it?
Thanks
Eric

Yes, clearly the question leads well outside the bounds of topicality.
But it seems unlikely these different results could be produced by the
same compiler with the same options, unless there is a difference in the
fpu mask settings, such as there is between 32- and 64-bit Windows, or
between most linux and some BSD OS.
May 20 '06 #7

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

reply views Thread by Knackeback | last post: by
31 posts views Thread by Bjørn Augestad | last post: by
2 posts views Thread by John Dann | last post: by
7 posts views Thread by Tor Aadnevik | last post: by
116 posts views Thread by Dilip | last post: by
8 posts views Thread by Grant Edwards | last post: by
11 posts views Thread by Steven Woody | last post: by
reply views Thread by mihailmihai484 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.