|
[Sponsors] |
November 14, 2006, 01:09 |
FORTRAN
|
#1 |
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 |
|
November 14, 2006, 01:35 |
Re: FORTRAN
|
#2 |
Guest
Posts: n/a
|
sorry some more info, to compile the above i used: make filename. i.e. not just make. regards again taw
|
|
November 14, 2006, 02:14 |
Re: FORTRAN
|
#3 |
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 |
|
November 14, 2006, 02:39 |
Re: FORTRAN
|
#4 |
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 |
|
November 14, 2006, 03:48 |
Re: FORTRAN
|
#5 |
Guest
Posts: n/a
|
Try increasing the precision to double precision.
|
|
November 14, 2006, 04:29 |
Re: FORTRAN
|
#6 |
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. |
|
November 14, 2006, 05:00 |
Re: FORTRAN
|
#7 |
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 |
|
November 14, 2006, 05:10 |
Re: FORTRAN
|
#8 |
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?
|
|
November 14, 2006, 05:25 |
Re: FORTRAN
|
#9 |
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.
|
|
November 14, 2006, 08:47 |
Re: FORTRAN
|
#10 |
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).
|
|
November 15, 2006, 01:37 |
Re: FORTRAN
|
#11 |
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 |
|
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Fortran Compiler-CFX12.1 | Araz | CFX | 13 | March 27, 2017 05:37 |
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 15:16 |
Why Favoring Fortran over C/C++? | Zi-Wei Chiou | Main CFD Forum | 35 | September 26, 2001 09:34 |