Comparing Real Numbers

[ahasan]

the following two variables are declared real: CavNum and MinSig0.

However, whenthe following if() statement is executed it writes

the values to afile as:

CavNum = 0.5001566410

MinSig0 = 0.5001566410

and the numbers appear identical.

if(CavNum .LT. MinSig0) then

.... code for write CavNum & MinSig0 to file using F16.10 fmt

end if

Two questions:

1) Why does the If() statement above consider the two numbers not equal?

2) Ifmemory represents the numbers with 32 bits, why are the numberswriten to file with 9 significant digits instead of 7?

Thanks for any comments.

Message Edited by halcyong@fcc.net on 09-15-2005 01:33 PM

Message Edited by halcyong@fcc.net on 09-15-2005 01:35 PM

[Steven_L_Intel1]

Just because they look identical when formatted in decimal doesn't mean they really are. Write out the hexadecimal form using a Z8.8 or Z16.16 (for double) format.

Single precision has 23 binary bits for the fraction. But if you used an F16.10 format, you'll get 10 digits to the right of the decimal point no matter what.

[ahasan]

Thanks Steve, Iwill try the hexadecimal format.

I thought that 23 bits would give a max of 7 significant digits, but don't understand why the 8th and 9th digits after the decimal pointof 0.5001566410 are greater than 0. I thought the mantissa of a real number (32 bits) could have only 7digits (or 7digits that have the possibility to be.GT. 0), all other displayed digits would be 0, but I am missing something.

[Steven_L_Intel1]

Yes, you're missing that the fraction is in base 2. The value you convert to decimal has (implied) zeroes beyond the 23 bits, but they are binary zeroes, not decimal zeroes. When converted to decimal, you get some value which is the "more precise" representation of the binary value.

I know that there are some implementations which just display zeroes after some number of digits. Those implementations are broken, in my opinion.

[TimP]

When the same library functions are employed to process single and double precision, they must be able to display 17 significant decimal places, for standard IEEE double precision. For single precision, 9 significant decimals are required to avoid degradation under conversion from binary to decimal and back. If you specify that degree of accuracy in formatted conversion, the run-time system is obligated to do what you ask.
What is missing in the preceding discussion is sufficient context to answer the question of why 2 numbers which appear to be the same after being written to a file were not the same when compared with an IF() test. It was not even specified whether the compiler was instructed to use SSE instructions (-xK, -xW, et al, without -fltconsistency or the like), thus supporting single precision expressions, or to use the default x87 instructions, where this type of inconsistency between double precision expressions and single precision stored values is expected.

[dima333a]

Well, it is very simple to check if two variables are really the same. Do not output them, just calculate the difference and send it to the screen

write(*,*) CavNum-MinSig0

If the variables are the same up the the last digit captured by the system, then you'll get 0, if not you'll get your difference.

Personally I do not like to make a strict comparison of reals in the way it is done in the first post. I had an experience, when I input 1.00000000, and machine (compiler) interperets it as 0.99999999999.... or sm. like that.

IMHO: It is more "safe" to compare real numbers with certain tolerance:

tol=0.000001

IF ( CavNum-MinSig0 .LT. tol) THEN

! I assume that CavNum=MinSig0

END IF

And tolerance can be set as "precision dependent" or "precision independent".

[ahasan]

Really appreciatethe informative discussions above. Thanks.