etxpnil@etxsj23.ericsson.se (Per Nilsson TT/SJG 98194 ) (09/28/90)
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 ?joseph@valnet.UUCP (Joseph P. Hillenburg) (09/29/90)
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. -Joseph Hillenburg UUCP: ...iuvax!valnet!joseph ARPA: valnet!joseph@iuvax.cs.indiana.edu INET: joseph@valnet.UUCP
uphwk@TERRA.OSCS.MONTANA.EDU (Bill Kinnersley) (09/29/90)
[In "Lattice C double" <R0L9P6w163w@valnet>,
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.ragg0270@uxa.cso.uiuc.edu (Richard Alan Gerber) (09/30/90)
A further SAS/C double question (since I can't get hold of them on the weekend). I am reading an ASCII file that contains columns of data w/ a construct like: FILE *fp; float *num1,*num2,*num3; int n; [...] num1 = (float *)AllocMem(sizeof(float), MEMF_PUBLIC|MEMF_CLEAR); etc... n = fscanf(fp,"%e%e%e\n",num1,num2,num3); [...] This works like a charm. But when I replace "float" with "double" everywhere it gives me total garbage. I don't know if the problem is with me (programming error), compiler settings or a compiler bug. Thanks for any help. Richard Gerber gerber@rigel.astro.uiuc.edu
walker@unx.sas.com (Doug Walker) (10/02/90)
In article <1990Sep29.193407.28644@ux1.cso.uiuc.edu> ragg0270@uxa.cso.uiuc.edu (Richard Alan Gerber) writes: >n = fscanf(fp,"%e%e%e\n",num1,num2,num3); > > >This works like a charm. But when I replace "float" with "double" >everywhere it gives me total garbage. I don't know if the problem is >with me (programming error), compiler settings or a compiler bug. >Thanks for any help. Try replacing your %e's with %le's when you switch to double. You have to tell fscanf that you are passing pointers to double instead of pointers to float. ***** =*|_o_o|\\=====Doug Walker, Software Distiller====== BBS: (919)460-7430 = *|. o.| || | o |// For all you do, this bug's for you! ====== usenet: ...mcnc!rti!sas!walker plink: dwalker bix: djwalker
jmeissen@oregon.oacis.org ( Staff OACIS) (10/02/90)
In article <1990Sep29.193407.28644@ux1.cso.uiuc.edu> ragg0270@uxa.cso.uiuc.edu (Richard Alan Gerber) writes: >A further SAS/C double question (since I can't get hold of them on the >weekend). [....] >n = fscanf(fp,"%e%e%e\n",num1,num2,num3); > >This works like a charm. But when I replace "float" with "double" >everywhere it gives me total garbage. You also need to change the format string, since it still assumes it is storing a 32-bit quantity instead of a 64-bit quantity. I believe it is "%le%le%le". -- John Meissen .............................. Oregon Advanced Computing Institute jmeissen@oacis.org (Internet) | "That's the remarkable thing about life; ..!sequent!oacis!jmeissen (UUCP) | things are never so bad that they can't jmeissen (BIX) | get worse." - Calvin & Hobbes
ken@cbmvax.commodore.com (Ken Farinsky - CATS) (10/02/90)
In article <1990Sep28.063045.2599@ericsson.se> 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 Are you using the correct compiler flags and linker options to get double-precision IEEE numbers? (compile with -fi, link with lcmieee.lib?) These results look like FFP or single precision IEEE numbers. -- -- Ken Farinsky - CATS - (215) 431-9421 - Commodore Business Machines uucp: ken@cbmvax.commodore.com or ...{uunet,rutgers}!cbmvax!ken bix: kfarinsky
wschmidt@phobix (Wolfram Schmidt) (10/04/90)
In article <1990Sep28.063045.2599@ericsson.se> 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 [...] I tried this with Aztec C 5.0a. With the MANX supplied libraries the result was O.K. With the Amiga IEEE libraries I got the same as above. With FFP the result was even worse. Wolfram -- Wolfram Schmidt wschmidt@iao.fhg.de Wolfram Schmidt Teckstr. 11 W-7056 Weinstadt Germany +49-7151/62408 MET
etxpnil@etxsj23.ericsson.se (Per Nilsson TT/SJG 98194 ) (10/04/90)
In article <14795@cbmvax.commodore.com> ken@cbmvax.commodore.com (Ken Farinsky - CATS) writes: >In article <1990Sep28.063045.2599@ericsson.se> 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 > >Are you using the correct compiler flags and linker options to get >double-precision IEEE numbers? (compile with -fi, link with >lcmieee.lib?) These results look like FFP or single precision >IEEE numbers. I've now tried it with the -fi switch and the lcmieee.lib, with the same result. I tried the new SAS/C V5.10 and I got the same result there.
ken@cbmvax.commodore.com (Ken Farinsky - CATS) (10/05/90)
In article <1990Oct4.063507.1899@ericsson.se> etxpnil@etxsj23.ericsson.se writes: >In article <14795@cbmvax.commodore.com> ken@cbmvax.commodore.com writes: >>In article <1990Sep28.063045.2599@ericsson.se> etxpnil@etxsj23.ericsson.se writes: >>>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 >> >>Are you using the correct compiler flags and linker options... > >I've now tried it...with the same result... Ok, how about: printf("%.9lg\n",dub); /* value is a long float (double) */ Nope, that doesn't do it. Looks like the problem is that you are displaying more than 15 digits, which is beyond the accuracy of the numeric format that you are using. If you use a smaller number (1234.0), then you get the result that you expect. Are the other machines that you are using this on using a different numeric format? -- -- Ken Farinsky - CATS - (215) 431-9421 - Commodore Business Machines uucp: ken@cbmvax.commodore.com or ...{uunet,rutgers}!cbmvax!ken bix: kfarinsky
rsbx@cbmvax.commodore.com (Raymond S. Brand) (10/05/90)
In article <14905@cbmvax.commodore.com>, ken@cbmvax.commodore.com (Ken Farinsky - CATS) writes: > In article <1990Oct4.063507.1899@ericsson.se> etxpnil@etxsj23.ericsson.se writes: > >In article <14795@cbmvax.commodore.com> ken@cbmvax.commodore.com writes: > >>In article <1990Sep28.063045.2599@ericsson.se> etxpnil@etxsj23.ericsson.se writes: > >>>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 > >> > >>Are you using the correct compiler flags and linker options... > > > >I've now tried it...with the same result... > > Nope, that doesn't do it. Looks like the problem is that you are > displaying more than 15 digits, which is beyond the accuracy of > the numeric format that you are using. If you use a smaller > number (1234.0), then you get the result that you expect. Are the > other machines that you are using this on using a different > numeric format? > -- > Ken Farinsky - CATS - (215) 431-9421 - Commodore Business Machines The problem is in printf. The binary result of the mult is exact. For some interesting reading on the problems and some solutions to the problems of translating floating-point numbers between different bases, read the two papers from the ACM SIGPLAN'90 conference proceedings: "How to Read Floating Point Numbers Accurately" William D Clinger, University or Oregon Pages 92-101 "How to Print Floating-Point Numbers Accurately" Guy L Steele Jr., Thinking Machines Corporation Jon L White, Lucid, Inc. Pages 112-126 rsbx ------------------------------------------------------------------------ Raymond S. Brand rsbx@cbmvax.commodore.com Commodore-Amiga Engineering ...!uunet!cbmvax!rsbx 1200 Wilson Drive (215)-431-9100 West Chester PA 19380 "Looking" ------------------------------------------------------------------------