Path: utzoo!attcan!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!usc!ucsd!ucbvax!TERRA.OSCS.MONTANA.EDU!uphwk From: uphwk@TERRA.OSCS.MONTANA.EDU (Bill Kinnersley) Newsgroups: comp.sys.amiga Subject: Re: Lattice C double Message-ID: <9009291318.AA03774@terra.oscs.montana.edu> Date: 29 Sep 90 13:18:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: uphwk@terra.oscs.montana.edu (Bill Kinnersley) Organization: Physics Department, Montana State University Lines: 50 [In "Lattice C double" , joseph@valnet.UUCP (Joseph P. Hillenburg) said:] :etxpnil@etxsj23.ericsson.se (Per Nilsson TT/SJG 98194 ) writes: : :> The following is a test program I've compiled with the Lattice C compiler. :> :> main() :> { :> double dub; :> :> dub = 12345678.0; :> :> dub = dub * 10.0; :> :> printf("%.9g\n",dub); :> } :> :> When compiled with the Lattice C V5.04, I've got the following output: :> :> 123456779.999999999 :> :> On my SPARC station I got the correct result: :> :> 123456780 :> :> Is this some kind of bug in the Lattice C compiler ? :> Is there any way around this problem ? : :Nope...just has to do with the way the different compilers use rounding. : In general you're right of course. However in this case all of the numbers are whole numbers, and small enough to be well within even the range of single precision. There should be no need for any rounding. The answer you get does depend on which math library you use. There is a generally accepted "right" way to handle floating point calculations, namely the IEEE standard, available on most machines and built in to the 8087 and 68881/2 chips. If you're using IEEE floating point and still get the answer you showed above, then yes I'd say it deserves to be called a bug. An extremely tiny error, but it's incredible how tiny errors like this can mushroom and overwhelm a calculation. -- --Bill Kinnersley Physics Department Montana State University Bozeman, MT 59717 INTERNET: uphwk@terra.oscs.montana.edu BITNET: UPHWK@MTSUNIX1 226 Transfer complete.