On May 13, 2:42=A0am, James Kanze <james.ka...@[EMAIL PROTECTED]
> wrote:
> On May 13, 7:16 am, Avi <avner-moshkov...@[EMAIL PROTECTED]
> wrote:
> > double f2 =3D e1 + e2;
> > The difference is calculated as follows:
> > double diff =3D f2-f1;
> > I expect the difference to be exactly 0 but instead, I get a
> > tiny value. =A0Could someone explain the reason for differences
> > in the result?
>
> It's very implementation dependent.
>
> > I'm compiling with gcc
>
> More to the point, you're compiling on a machine which uses
> extended precision in its floating point unit, and its floating
> point registers. =A0(An Intel, perhaps.)
>
> The reason for this freedom is speed. =A0Forcing the results of
> each operation to be rounded to double can be done, but would
> slow things down considerably (at least on Intel). =A0And for the
> most part, increased precision is not considered a defect.
But the extended floating point precision is a defect if - as in this
case - consistent numeric results are required. Fortunately, all Intel
x86 chips since the Pentium 3 sup****t double precision (64-bit)
floating point in their SSE units. So, the solution would be to have
the compiler generate SSE floating point instructions ("-msse2 -
mfpmath=3Dsse") instead of 387 instructions. According to the gcc
do***entation, this strategy has other benefits as well:
"The resulting code should be considerably faster in the majority of
cases and avoid the numerical instability problems of 387 code, but
may break some existing code that expects tem****aries to be 80-bit."
Greg
|
