Fortran jump command for fortran 95

  • Context: Fortran 
  • Thread starter Thread starter buddhanath
  • Start date Start date
  • Tags Tags
    Fortran Jump
Click For Summary
SUMMARY

The forum discussion centers on a Fortran 95 program encountering an issue with undefined labels in a GOTO statement. Users emphasize that labels must be correctly positioned within the first five columns of the code for the compiler to recognize them. Additionally, they advise against using GOTO statements in favor of structured programming techniques like DO-WHILE loops to enhance code readability and maintainability. The discussion highlights the importance of breaking down complex equations into simpler statements to facilitate debugging and prevent syntax errors.

PREREQUISITES
  • Understanding of Fortran 95 syntax and structure
  • Familiarity with GOTO statements and their implications
  • Knowledge of debugging techniques in Fortran
  • Experience with structured programming concepts, particularly DO-WHILE loops
NEXT STEPS
  • Learn how to properly format labels in Fortran 95
  • Explore the use of DO-WHILE loops as an alternative to GOTO statements
  • Investigate best practices for breaking down complex expressions in Fortran
  • Utilize debugging tools and IDEs for Fortran to improve code quality
USEFUL FOR

This discussion is beneficial for Fortran developers, programmers transitioning from older versions of Fortran, and anyone looking to improve their coding practices and debugging skills in Fortran 95.

buddhanath
Messages
2
Reaction score
0
Even after writing the label , it is showing that label is not defined, please help!
my program reads...…...
……...
Fortran:
99 z = b + 2*c*(d - 0.0792079*(e + log((( sqrt(x) + 1.52569)**5.64616)/(((sqrt(x) - 1.26704)**5.93863)*((sqrt(x) - 0.258652)**50.2075)))) - 2 log(x))
zs = g + 2*i*(d - 0.0792079*(e + log((( sqrt(x) + 1.52569)**5.64616)/(((sqrt(x) - 1.26704)**5.93863)*((sqrt(x) - 0.258652)**50.2075)))) - 2 log(x)) + 2*j*(-0.0792079*( k-l +( (m-n-o)*p)/q + r))
h = -z/zs
tol= 0.0001
x= x+h
if (abs(h) .gt. tol) then
  goto 99
  else
  print*, "the root of the equaton is ", x
end if
end program
 
Last edited by a moderator:
Technology news on Phys.org
PLEASE ... use the "code" tag so your post doesn't look so sloppy.
 
  • Like
Likes   Reactions: Wrichik Basu
I know nothing in Fortran, but it seems that the label 99 should be defined after it is mentioned in a goto statement.
 
  • Sad
Likes   Reactions: Vanadium 50
Wrichik Basu said:
I know nothing in Fortran, but it seems that the label 99 should be defined after it is mentioned in a goto statement.
No. The compiler figures out the labels before it tries to run, so the label can be defined before it is referenced.
The original versions of FORTRAN were very column-dependent. Anything in column 1 was the beginning of a comment. There were a lot of column rules. I would check into that. The first 5 columns were for labels. Anything in column 6 meant that the following is a continuation of the prior row. Code was not allowed to go beyond column 72. I do not know about the modern versions.

It often helps to see the exact error message and what line and column it thinks the error is on.
It also often helps to know what version of FORTRAN you are using.
 
Last edited:
  • Like
  • Informative
Likes   Reactions: Vanadium 50, Wrichik Basu and berkeman
Its FORTRAN 95. It only shows problem sometimes when I am using big equations
 
Clearly, this is just part of the program. It is not possible to know if everything was defined and compiled successfully. If long equations seem to cause a problem, see if breaking up the equation into a few steps solves the problem. If so, then you have narrowed down where to look. If not, something else went wrong.
 
A wise man once said:
Vanadium 50 said:
"Check my work" is a really heavy ask.

You can make it easier with well-documented code, easy to understand variable names and logic structure, and the minimum example needed to demonstrate the problem.

  1. This is not complete code.
  2. "It only shows problem sometimes when I am using big equations" is annoying. Does this code show the problem or not?
  3. FORTRAN has no "jump" statement. Yes, we can figure out what you mean, but we shouldn't have to. Sloppy writing makes us work harder, just as sloppy thinking makes you work harder.
  4. If you are really using FORTRAN 95 you should not be messing with GOTO's. You should use some other structure, perhaps DO-WHILE. That is not some exotic function new to FIRTRAN 95 (itself a quarter-century old). It was in FORTRAN 77.
 
Last edited:
  • Like
Likes   Reactions: FactChecker
The GOTO is notorious because of extreme examples of "spaghetti code". But using it in simple ways should work with no problems. It certainly is frowned on by those who have been traumatized by the bad examples so it's a good habit to avoid it. In any case, you should always indent the interior of the loop so people (including you) can easily see it.
 
Last edited:
Vanadium 50 said:
If you are really using FORTRAN 95 you should not be messing with GOTO's.
This, especially (not that the other parts aren't also valid).

If you must use goto, I suspect that the problem is that the label 99 is not in the right place; i.e., somewhere in columns 1 through 5. Because it likely is not located correctly, the compiler doesn't know that you intend it to be a label.
 
  • Like
Likes   Reactions: Vanadium 50 and FactChecker
  • #10
buddhanath said:
It only shows problem sometimes when I am using big equations
These aren't equations -- they are assignment statements where the stuff on the right side is some expression you want to evaluate. As already mentioned, best practice is to break up these big expressions. Doing so makes debugging a lot easier.

You are using a debugger, right?
 
  • Like
Likes   Reactions: Vanadium 50 and FactChecker
  • #11
I agree with all the recommendations above; using an IDE with a debugger (or a syntax-checking code editor), breaking up long assignment statements, using do...while instead of goto, taking note of all compiler errors and warnings - these would all help you find the problem yourself.

But this once I'll find it for you - the first line you posted contains the code 2 log(x) which is not correct and prevents the line from compiling so the label 99 is not created.

This should presumably be 2 * log(x).
 
  • Like
Likes   Reactions: Wrichik Basu, Vanadium 50 and Ibix
  • #12
Lessons from @pbuk's message:

0. I see you've been back but haven;t responded to the excellent advice you have received. That's not a good way to get more help.
1. He spotted a syntax error in Line 1. There's also one in Line 2. You never mentioned these to us - just the one on Line 7.
2. If you don't tell us all of the error messages you are getting, it will be very hard for us to figure out the problem.
 
  • #13
pbuk said:
This should presumably be 2 * log(x).
Good catch! I didn't scroll to the right on these long code lines, so missed this one, and the similar error on the next line. This is another reason that argues against using overly long and complicated expressions in assignment statements.
 

Similar threads

Replies
2
Views
2K
  • · Replies 11 ·
Replies
11
Views
3K
  • · Replies 1 ·
Replies
1
Views
2K
  • · Replies 10 ·
Replies
10
Views
26K
Replies
9
Views
2K
  • · Replies 3 ·
Replies
3
Views
16K
  • · Replies 1 ·
Replies
1
Views
11K
  • · Replies 54 ·
2
Replies
54
Views
5K
  • · Replies 1 ·
Replies
1
Views
3K
  • · Replies 2 ·
Replies
2
Views
2K