UH2@PSUVM.BITNET (Lee Sailer) (10/11/88)
I have stumbled onto one of those C mystery problems, using Lattice 4.01.
INT_MAX is a #define for the largest int. In my code I have
r1 = 1.0/(double)INT_MAX
and
double im = INT_MAX;
r2 = 1.0/im;
Guess what? r1 and r2 get different values. How come?
This only occurs with FFP. I know it isn't as accurate ,but I didn't
expect it to be crazy.
lee
#include <limits.h>
#include <stdio.h>
main()
{
double r1, r2, r3, im=INT_MAX;
int iim = INT_MAX;
r1 = 1.0/(double)INT_MAX;
r2 = 1.0/im;
r3 = 1.0/(double)iim;
printf("r1 == %g, r2 == %g, r3 == %g.\n", r1, r2, r3);
return 0;
}
With FFP, r1 == r2 != r3. With IEEE, they are equal, and have a
differnt value from either with FFP.
mills@baloo.eng.ohio-state.edu (Christopher Mills) (10/11/88)
In article <56733UH2@PSUVM> UH2@PSUVM.BITNET (Lee Sailer) writes: > [ Why do these give different answers using FFP ] > r1 = 1.0/(double)INT_MAX Lattice can do this at compile time, and probably uses double precision. > double im = INT_MAX; > r2 = 1.0/im; Latice dose this at runtime using FFP and gets a different answer due to roundoff. (at least that's my guess...) -=- _________________________________________________________________________ | Christopher Mills | "If you see someone without a smile, | | mills@baloo.eng.ohio-state.edu | give them mine - I'm not using it." | ====== My thoughts are not my own--I'm posessed by mailer daemons. ======
dillon@CORY.BERKELEY.EDU (Matt Dillon) (10/12/88)
:I have stumbled onto one of those C mystery problems, using Lattice 4.01. : :INT_MAX is a #define for the largest int. In my code I have : : r1 = 1.0/(double)INT_MAX : :and : : double im = INT_MAX; : r2 = 1.0/im; : :Guess what? r1 and r2 get different values. How come? : : .. only FFP The reason is that the first line, 1.0/(double)INT_MAX is a constant expression which is evaluated at compile time, using the maximum precision available to the compiler. The second line is evaluated run-time by the FFP library. Since the FFP representation of the maximum-sized integer looses some accuracy (you cannot represent a 32 bit-sized non-power-of-2 integer with a 32 bit FFP quantity without some error), the evaluation comes out slightly flawed. -Matt