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