CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > Main CFD Forum

FORTRAN

Register Blogs Members List Search Today's Posts Mark Forums Read

Reply
 
LinkBack Thread Tools Display Modes
Old   November 14, 2006, 02:09
Default FORTRAN
  #1
taw
Guest
 
Posts: n/a
Can anyone tell me the reason why i get 0.400000006 instead of 0.4, when i divide 2 by 5 using fortran routines. The routines are as follows.

real i,k,j

k=2

j=5

a=K/j

i=k/j

j=real(k/j)

print*,i

print*,a

print*,j

stop

end

the results for a,i,j is 0.400000006. I use fortran compiler g77.

regards. taw
  Reply With Quote

Old   November 14, 2006, 02:35
Default Re: FORTRAN
  #2
taw
Guest
 
Posts: n/a
sorry some more info, to compile the above i used: make filename. i.e. not just make. regards again taw
  Reply With Quote

Old   November 14, 2006, 03:14
Default Re: FORTRAN
  #3
Ford Prefect
Guest
 
Posts: n/a
Try declaring your variables as

program DUMMY real a,b,c

a=2.d0 b=5.d0 c=a/b

write(*,*) 'a/b= ', c

stop end

Regards FP
  Reply With Quote

Old   November 14, 2006, 03:39
Default Re: FORTRAN
  #4
taw
Guest
 
Posts: n/a
sir, I wrote u'r rotines on separate lines as follows;

program DUMMY

real a,b,c

a=2.d0

b=5.d0

c=a/b

write(*,*) 'a/b= ', c

stop

end

naming the filename=try.f

compiled it as; make try

I got the following complilation message : f77 try.f -o try

and run the program as: try enter

the result for me is :

a/b= 0.400000006.

Is there a procedure i am missing, or my computer or OS has bugs.

regards,

TAW

  Reply With Quote

Old   November 14, 2006, 04:48
Default Re: FORTRAN
  #5
Ford Prefect
Guest
 
Posts: n/a
Try increasing the precision to double precision.
  Reply With Quote

Old   November 14, 2006, 05:29
Default Re: FORTRAN
  #6
Renato.
Guest
 
Posts: n/a
The problem is not your compiler or OS (or shouldn't be at least). When doing floating point operations you'll need to use compatible types in order to avoid what is called "cast" of variables. We could take the Ford Prefect example:

program DUMMY real a,b,c a=2. b=5. c=a/b write(*,*) 'a/b= ', c stop end

or, in double precision

program DUMMY real*8 a,b,c a=2.d0 b=5.d0 c=a/b write(*,*) 'a/b= ', c stop end

NOTE: Not always you'll get what you're waiting in floating point arithmetics. The machine has a limitation in its internal representation of floating numbers and sometimes some information can be lost. It's easier to happen when using single precision.

Regards

Renato.

  Reply With Quote

Old   November 14, 2006, 06:00
Default Re: FORTRAN
  #7
M.Lipinski
Guest
 
Posts: n/a
Taw,

Real arithmetic gives precision of about 8 significant digits, this is what you observe. Try to declare everything as real*8 and use 2.0d+0 (or 5.0d+0) format to set constants then your results should be about 15 digits accurate.

regards

M.Lipinski
  Reply With Quote

Old   November 14, 2006, 06:10
Default Re: FORTRAN
  #8
Ford Prefect
Guest
 
Posts: n/a
Slightly off topic, but recently I started using gfortran instead of g77. There are some differences in output at runtime between the two compilers (e.g. the auto-format '*' option in write statements behaves differently). Is this difference attributed to the fact that g77 is fortran 77 and gfortran is fortran 95?
  Reply With Quote

Old   November 14, 2006, 06:25
Default Re: FORTRAN
  #9
Steve
Guest
 
Posts: n/a
In addition to the other answers given, the root cause of the problem is that 0.4 (decimal) cannot be represented exactly in binary in a finite number of figures, meaning that the IEEE floating point representation is going to be the best approximation possible. Fractions such as 0.5 (0.1), 0.25 (0.01), 0.125(0.001), 0.375 (0.011) are fine, but just try to convert 0.4.
  Reply With Quote

Old   November 14, 2006, 09:47
Default Re: FORTRAN
  #10
Fuka
Guest
 
Posts: n/a
Format * is up to compiler. Every has it's own specification and it is not guarantied to be the same on another compiler (not only f77 vs f90 but also different brands). If you want the same output format on every compiler use precise specification (eg A, F, G ... with parameters).
  Reply With Quote

Old   November 15, 2006, 02:37
Default Re: FORTRAN
  #11
taw
Guest
 
Posts: n/a
Dear sirs,

Thankyou all for thevery helpful discussions. I was finally able to obtain the right answer by using real*8. It was a big relief since I was to mess up with my computer, you saved me a lot.

Alas my big worry now becomes how many of my past simulations my have caried garbages since i was not that curious or bother to add *8 or for that matter double precison statement whenever i modify past codes.

I will one day go throgh my past results in this light.

Best regards to all. TAW
  Reply With Quote

Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
Fortran Compiler-CFX12.1 Araz CFX 12 November 2, 2014 13:46
Intrinsic Procedure 'ISNAN' in GNU FORTRAN 77 hawk Main CFD Forum 1 April 12, 2005 22:13
visual fortran Monica Main CFD Forum 1 August 28, 2004 20:45
Fortran77 or Fortran 90 Swapnil CFX 2 November 26, 2002 16:16
Why Favoring Fortran over C/C++? Zi-Wei Chiou Main CFD Forum 35 September 26, 2001 09:34


All times are GMT -4. The time now is 20:39.