CVF/IVF Floating-point accuracy

[ocean]

I'm in the process of validating an application that has recently been migrated from CVF 6.6 to IVF 9.0, on Windows 2000. When comparing results between the two applications I have noticed small differences in floating-point calculations. As an example take the following code:

REAL*4 Mag, V(3)

V(1) = -140.83720397949219

V(2) = 381.26318359375

V(3) = -85.774497985839844

Mag = SQRT(V(1)**2 + V(2)** + V(3))

The above code produces the falling results for each compiler:

Mag = 415.396209716796875 (IVF)

Mag = 415.39617919921875 (CVF)

I expected both compilers to produce the same result, but that is not the case. I used the IVF Wizard to do the migration, and I assume that floating-point compiling options are the same for both applications.

I understand that if accuracy is so important, the original developers of the application should have used double precision variables, but they didn't. I'm trying to figure out if there's a way of arriving at the same result without having to go through the code and change REAL*4 to REAL*8. Perhaps there's a special compiler option, that I'm not aware of, that can be invoked to arrive at same result.

Thanks for your help,

Manny

[TimP]

Setting /fltconsistency, for both CVF and ifort, should minimize numerical differences between them. As they are designed for different architectures, the idea of making the numerical results identical is usually impractical.
In the case you quote, which appears to permit evaluation at compile time, it is possible that ifort is stricter about following the Fortran standard, so setting /fpconstant or /nofpconstant for both compilers may help. I could read your statement as if you expect /fpconstant to be the default, but that is contrary to the Fortran standard. Both compilers also support /4R8 as an option to promote default REAL (but not REAL*4) to double precision.

[g_f_thomas]

---

[email protected] wrote:

I'm in the process of validating an application that has recently been migrated from CVF 6.6 to IVF 9.0, on Windows 2000. When comparing results between the two applications I have noticed small differences in floating-point calculations. As an example take the following code:

REAL*4 Mag, V(3)

V(1) = -140.83720397949219

V(2) = 381.26318359375

V(3) = -85.774497985839844

Mag = SQRT(V(1)**2 + V(2)** + V(3))

The above code produces the falling results for each compiler:

Mag = 415.396209716796875 (IVF)

Mag = 415.39617919921875 (CVF)

I expected both compilers to produce the same result, but that is not the case.

>>>>>>>>>>>>>>(Me)

And so they did!

In real*4 the digital accuracy in the computed result is ~-log10(eps), where eps =2^-23: ie, about 7 decimal digits. Ascribing significance to digits beyond 7 is a waste.

>>>>>>>>>>>>>>>>>>(You)

I understand that if accuracy is so important, the original developers of the application should have used double precision variables, but they didn't.

>>>>>>>>>>>>>>>>>>>(Me)

I've no idea why anyone would use single over double precision. Also, stick to fpconsistency and don't sweat the small stuff.

HTH,

Gerry T.

---

[ocean]

Thanks for your response. As per your suggestion, I have set both compilers to /fltconsistency and /fpconstant, and I havent seen any difference in results for the case I provided in my first posting. Nothing appears to have changed; unless these compiler options are being overridden by some other option.

Thanks,

Manny

[jimdempseyatthecove]

>>I've no idea why anyone would use single over double precision.

If the precision is not required then

Memory footprint

Speed - under the right circumstances SSE3 can chew on 4 variables at a time as opposed to 2 variables at a time.

Jim Dempsey