0

When I run my code with Silverfrost fortran, the result is -2.987531633638E-02. But with gfortran (under cygwin and ubuntu linux) it is -2.9875316336381942E-002. My code is here:

program seebeck

real*8::ss
integer::ix,i
complex,parameter::i1=(0.0,1.0)

call quad3d(0.,190.,ss)
write(*,*) "result:",ss
stop
end program seebeck

  SUBROUTINE quad3d(x1,x2,ss)
  REAL:: x1,x2
  external f1
  real*8::ss,f1
  call qgausep(f1,x1,x2,ss)
  return
  END
  SUBROUTINE qgausep(f2,a,b,ss)
  external f2
  REAL:: a,b
  real*8::ss,f2
  INTEGER j
  REAL*8 dx,xm,xr,w(5),x(5)
  SAVE w,x
  DATA w/.2955242247,.2692667193,.2190863625,.1494513491,.0666713443/
  DATA x/.1488743389,.4333953941,.6794095682,.8650633666,.9739065285/
  xm=0.5*(b+a)
  xr=0.5*(b-a)
  ss=0
  do 11 j=1,5
    dx=xr*x(j)
    ss=ss+w(j)*(f2(xm+dx)+f2(xm-dx))
  11    continue
  ss=xr*ss
  return
  END

  function f1(t)
  real*8::t,f1
  f1=cos(t)/(1+exp(t))**2
  end function

There is a huge difference between the two results. I cannot explain the cause of this difference as a floating point inaccuracy.

Note: My code is a draft version and has no physical meaning.

agentp
  • 6,849
  • 2
  • 19
  • 37
berna uyanık
  • 21
  • 3
  • 5
    Huge difference? Results agree to 12 decimal places. The difference most likely comes from the use of list-directed output - the compiler is free to choose whatever format it deems fit. Give an explicit format and fix the number of decimal digits in the edit descriptor, only then compare the results and claim that they are different. – Hristo Iliev Nov 04 '15 at 11:48
  • What do you mean by "huge difference"? To me it looks like your outputs agree to their common precision. What if you use an explicit format matching the output you currently have from gfortran, rather than letting each compiler arbitrarily choosing its own format? – francescalus Nov 04 '15 at 11:48
  • Please try using `write(*, "(a, es30.20)")` instead of `write(*,*)` for outputting `ss`, for example. The former way (explicit format) prints more digits. – roygvib Nov 04 '15 at 20:15

1 Answers1

2

This has something to do with how different compilers handling your data assignment at line 26/27 of your code. You defined both w and x as double-precision arrays, but only initialize them with lower precision values. This will introduce some floating point inaccuracy. In fact if I pass your code through the NAG compiler (which is known to be very strict), it gives a warning:

Warning: test.f90, line 26: Low-precision data-value assigned to high-precision data-object

To confirm, you can print out the values in array w and x to see if they are different when using different compilers.

macelee
  • 321
  • 2
  • 7
  • 3
    This (and a bunch of other low precision literals) should be definitely fixed , but I would expect both compilers to handle the conversion the same way. – agentp Nov 04 '15 at 16:47