Xref: utzoo comp.lang.c:11792 comp.std.c:264 sci.math:4375
Path: utzoo!utgpu!water!watmath!clyde!bellcore!rutgers!apple!turk
From: turk@Apple.COM (Ken "Turk" Turkowski)
Newsgroups: comp.lang.c,comp.std.c,sci.math
Subject: Re: Floating point puzzle
Keywords: floating point representation
Message-ID: <15370@apple.Apple.COM>
Date: 10 Aug 88 23:29:13 GMT
References: <3117@emory.uucp>
Reply-To: turk@apple.com.UUCP (Ken "Turk" Turkowski)
Organization: Advanced Technology Graphics, Apple Computer, Cupertino, CA, USA
Lines: 31

In article <3117@emory.uucp> riddle@emory.uucp (Larry Riddle) writes:
>	float x,y;
>	x = 1.0/10.0;
>	y = 1677721.0/16777216.0; 
>	printf("x: %x",x);
>	printf("%20.17f\n",x);
>	printf("y: %x",y);
>	printf("%20.17f\n",y);
>Here is the output:
>
>x: 3fb99999 0.10000000149011612 
>y: 3fb99999 0.09999996423721313
>
>Notice that x and y, which have been declared as floats, and thus have
>a 32 bit representation (according to the manual this obeys IEEE
>floating point arithmetic standards), both are printed the same in hex,
>but give different values when printed as floats. I believe that the
>hex is a straight translation of the internal bit representation. The
>division in computing x and y is done in double precision (64 bits) and
>then converted to floats.

The problem is that floats are converted to doubles (or extendeds on the
macintosh).  A double has an 11-bit exponent, whereas a float only has 8.
If you print out the next word, you'll see that the two hex representations
differ somewhere in the next 3 bits.
Ken Turkowski @ Apple Computer, Inc., Cupertino, CA
UUCP: {mtxinu,sun,decwrl,nsc,voder}!apple!turk
CSNET: turk@Apple.CSNET
ARPA: turk%Apple@csnet-relay.ARPA
Domain-based address: turk@apple.com