Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.

Internal Precision Problem?

kyudos
Beginner
610 Views
Previously (in CVF 6) this code worked:

[fxfortran]poly.area = 0.0 Do i = 1, poly.cnt - 1 poly.area = poly.area + (poly.xy(1, i) * poly.xy(2, i + 1) - poly.xy(1, i + 1) * poly.xy(2, i)) End Do poly.area = 0.5 * Abs(poly.area)[/fxfortran]Where poly.area and poly.xy are Real*4.

Since upgrading to IVF XE 2011 i need to do this to get the same answer:

[fxfortran]poly.area = 0.0 Do i = 1, poly.cnt - 1 poly.area = poly.area + (Dble(poly.xy(1, i)) * Dble(poly.xy(2, i + 1)) - Dble(poly.xy(1, i + 1)) * Dble(poly.xy(2, i))) End Do poly.area = 0.5 * Abs(poly.area)[/fxfortran]I don't much fancy trying to find out where this might be a problem in my code, is there a compiler option to make IVF work like CVF in this regard?

Cheers!
0 Kudos
3 Replies
mecej4
Honored Contributor III
610 Views
If your variables are declared (explicitly or implicitly) as single precision real, whereas double precision is expected and needed to obtain satisfactory results, the code is defective in that the expectations are not in conformity with the Fortran standards.

On the 80x87 APU, register-register arithmetic is performed on 80-bit ("extended precision") floating-point quantities, and that may be why the code performed satisfactorily when compiled with CVF, particularly in situations in which a double precision sum is accumulated and put into 32- or 64-bit memory locations only after the operation is complete.

Look at the /real-size:xxx option as a temporary solution to the problem.
0 Kudos
TimP
Honored Contributor III
610 Views
In addition to what mecej4 said, if you put parentheses around the subtraction and set /assume:protect_parens that may solve the issue. We frequently see applications written that way so as to group subtraction appropriately to reduce roundoff error, but ifort will not follow the standard unless you set protect_parens or one of the /fp: options which implies protect_parens (and disallows algebraic simplification in violation of parentheses).
0 Kudos
kyudos
Beginner
610 Views
After some reading around I found that /fltconsistency did the trick.

My code comes from the era where variable size mattered in terms of storage and speed of execution. It would be nice to go through it and 'upgrade' it all to double precision, but there are too many implications to doing that at the moment!
0 Kudos
Reply