Precision Problem.

Precision Problem.

Hi,

I need some help please. Well I'm writing because I have a problem with the precision when I realize some simple operation or when I read some value from a file. For example in some file I must read 0.3, but Fortran reads 0.29999999999999999, that it is very close to 0.3, but it is not 0.3. On the other hand when I multiplied the same number in two different codes, I obtain different result; the unique difference is that in one code I use 1.1d0 and in the other I use 1.1. I'm working with double precision, and these problem are causing me error in my results. Then I show two codes that show the difference in accuracy (both have equal input values).

CODE Version 1:

DO j = 1,cp
jj = cl(j,i)
xx = p(jj)%x
yy = p(jj)%y
dx = xx - x
dy = yy - y
dd = DSQRT(dx**2.0d0+dy**2.0d0)
IF (dd > dmax) dmax = dd
END DO
beta = 1.1d0*dmax

CODE Version 2.

DO J=1,NPUNTOS(INOD)
DX=X(CL(J,INOD))-XS
DY=Y(CL(J,INOD))-YS
DIS=SQRT(DX**2+DY**2)
IF (dmax(inod).LT.DIS) dmax(inod)=DIS
END DO
BETA=dmax(inod)*1.1

Sorry for my english. and thank you in advance.

Regards.

Felipe.

5 posts / 0 nouveau(x)
Reportez-vous à notre Notice d'optimisation pour plus d'informations sur les choix et l'optimisation des performances dans les produits logiciels Intel.

There are a number of red herrings in your questions, but the key point is that computers do their arithmetic and representation of numbers in binary rather than decimal, so while 1.1 may appear to you to be a number that can be represented exactly, to the computer it is a number whose representation is a repeating fraction, analogous to 1 and 1/7 being 1.142857142857... in decimal.  For any given number of binary digits, the computer can use the closest number it has to 1.1 using that number of digits, but it willnot be exact.

In the first code sequence, you used 1.1d0, which a double precision constant, about as precise as using 1.142857142857143 for 1 and 1/7.  Inthe second sequence, you used 1.1, which is a single precision constant, only about as precise as using 1.142857 for 1 and 1/7.  Thus, it should come as no surprise that the first sequence gives better results.

If your variables are declared double precision, 1.1 will be converted to a double precision value, but unfortunately this is like converting 1.142857 to 1.142857000000000.  It may be a double precision value, but isn't the double precision value you would want for best double precision results.

Thank you for answering. Ok, so I am clear about the differences existing in the codes; but I do not know if you could help me also with respect to the issue of reading a value from a file, that is reads only approximately (eg. 0.3 in the file is read as 0.299999999999999 in double precision). Sorry for inconvenience and thanks.

Regards.

Quote:

Felipe Marchant wrote:

Thank you for answering. Ok, so I am clear about the differences existing in the codes; but I do not know if you could help me also with respect to the issue of reading a value from a file, that is reads only approximately (eg. 0.3 in the file is read as 0.299999999999999 in double precision). Sorry for inconvenience and thanks.

Regards.

This is, effectively, the same problem.  0.3 is another number whose representation in binary is a repeating fraction.  The I/O library can only produce the closest binary number to what your file contains.  If you print out that result to enough digits, you can see the difference.  Ideally, if that number is being read into a double precision variable, the I/O library should produce the same approximate representation as the compiler chooses for 0.3d0, and if that number is being read into a single precision variable, the I/O library should produce the same approximate representation as the compiler chooses for 0.3 or 0.3e0, but in either case, the value stored in the varikable is still only an approximation of the decimal value being presented.  Except in very special cases, the expectation that floating point numbers will represent the result of any operation exactly is contrary to the reality of computer arithmetic and likely to lead you into trouble.

Thank you very much.