# Problems when averaging a value

• Fortran
Hi,
I am running a fortran 90 program and I have some problems when getting an average. It happens that at some point the value of suma2 is not updated, even when the value of the term s(fixed2(j))/real(nfixed) is not zero. Below is the output of fort.32. The problem dissapears when suma2 is declared as real(8), could anyone please tell me the reason?

Thank you very much
Code:
real :: suma2

10 do i = 1, ncycle

call   mc_swap_thermo(n1,nsites,s,sorted,beta,lambda,seed,neigh,iacc,fixed1,fixed2,nfixed,sblock,sfixed,switch_thermo)

do j = 1, nfixed

suma2 = suma2 + s(fixed2(j))/real(nfixed)
write(32,*) suma2, s(fixed2(j)), s(fixed2(j))/real(nfixed)

end do

steps=steps+1

end do

262144.000       0.00000000       0.00000000
262144.000      0.139704779       1.16420649E-02
262144.000       0.00000000       0.00000000
262144.000      0.139704779       1.16420649E-02
262144.000       0.00000000       0.00000000
262144.000      0.139704779       1.16420649E-02
262144.000       0.00000000       0.00000000
262144.000      0.139704779       1.16420649E-02
262144.000      0.139704779       1.16420649E-02

Last edited by a moderator:

Related Programming and Computer Science News on Phys.org
jedishrfu
Mentor
I think the real(8) increases the precision to double ie 64-bit precision whereas the real or real(4) is only 32-bit precision.

• jbenet
Mark44
Mentor
Hi,
I am running a fortran 90 program and I have some problems when getting an average. It happens that at some point the value of suma2 is not updated, even when the value of the term s(fixed2(j))/real(nfixed) is not zero. Below is the output of fort.32. The problem dissapears when suma2 is declared as real(8), could anyone please tell me the reason?

Thank you very much

real :: suma2

10 do i = 1, ncycle

call mc_swap_thermo(n1,nsites,s,sorted,beta,lambda,seed,neigh,iacc,fixed1,fixed2,nfixed,sblock,sfixed,switch_thermo)

do j = 1, nfixed

suma2 = suma2 + s(fixed2(j))/real(nfixed)
write(32,*) suma2, s(fixed2(j)), s(fixed2(j))/real(nfixed)

end do

steps=steps+1

end do

262144.000 0.00000000 0.00000000
262144.000 0.139704779 1.16420649E-02
262144.000 0.00000000 0.00000000
262144.000 0.139704779 1.16420649E-02
262144.000 0.00000000 0.00000000
262144.000 0.139704779 1.16420649E-02
262144.000 0.00000000 0.00000000
262144.000 0.139704779 1.16420649E-02
262144.000 0.139704779 1.16420649E-02
What you're encountering is the difference in precision between real (4 bytes) and real(8) (8 bytes). With 4-byte reals, you have only about 7 digits of precision. When you add .0116 to 262144.00, the change is too small to affect the larger number. Changing to 8-byte reals gives you precision out to 12 or 13 places, if I'm remembering correctly.

• jbenet
DrClaude
Mentor
Changing to 8-byte reals gives you precision out to 12 or 13 places, if I'm remembering correctly.
real*8 is the same as double in C, so the machine epsilon is 2−52 ≈ 2.22e-16, giving 15 to 16 decimal places.

• jbenet and Mark44
Ok, I understand now. Thank you very much