forums.silverfrost.com Forum Index forums.silverfrost.com
Welcome to the Silverfrost forums
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

This baffles me

 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> General
View previous topic :: View next topic  
Author Message
Zach



Joined: 13 Mar 2023
Posts: 85
Location: Groningen, Netherlands

PostPosted: Wed May 10, 2023 10:25 pm    Post subject: This baffles me Reply with quote

I am a little afraid to ask this, however:

program banana
integer::n
print*,'The Result'
do while(n < 4)
n = n + 1
print*,n
end do
print* !This line
read *
end program banana

When "This line" is missing, nothing at all is printed
Why is that so?
Back to top
View user's profile Send private message Send e-mail
Kenneth_Smith



Joined: 18 May 2012
Posts: 696
Location: Hamilton, Lanarkshire, Scotland.

PostPosted: Wed May 10, 2023 11:24 pm    Post subject: Reply with quote

You need to assign an initial value to n before entering the DO WHILE / END DO loop.

When n = “undefined”, n = n + 1 is also “undefined”.

Compiling the program using Checkmate would have identified the undefined state of n at run time.

Code:
program banana
integer::n
n = 0
print*,'The Result'
do while(n < 4)
n = n + 1
print*,n
end do
!print* !This line
read *
end program banana
Back to top
View user's profile Send private message Visit poster's website
wahorger



Joined: 13 Oct 2014
Posts: 1185
Location: Morrison, CO, USA

PostPosted: Wed May 10, 2023 11:43 pm    Post subject: Reply with quote

The code
Code:
print * !This Line

Shows nothing because the exclamation mark denotes everything following it will be a comment. You will get a blank line, but that's really useless, yes?

And Kenneth is also correct. Since you do not know the starting value of "n" (it can be random), the loops may not run, or may run for a very long time.

One error/warning you can get when you compile is that a variable has been used without having an initial value.

Bill
Back to top
View user's profile Send private message Visit poster's website
Zach



Joined: 13 Mar 2023
Posts: 85
Location: Groningen, Netherlands

PostPosted: Thu May 11, 2023 12:15 am    Post subject: Reply with quote

#include <stdio.h>
int main()
{
int n;
do
{
n = n + 1;
printf("%d",n);
}while(n < 4);
}

Adding to something undefined, results in something else undefined, sounds very logical. But, indeed adding a starting value, removes the problem. However, in C the problem does not arise.
Back to top
View user's profile Send private message Send e-mail
Kenneth_Smith



Joined: 18 May 2012
Posts: 696
Location: Hamilton, Lanarkshire, Scotland.

PostPosted: Thu May 11, 2023 1:04 am    Post subject: Reply with quote

The Fortran standard clearly says that the default value of a Fortran variable is UNDEFINED.

You must not to rely on the 0 initialization you may experience using some Fortran compilers; while this is convenient these compilers are not behaving correctly and this can cause havoc when you switch compilers.

It is possible to specify an initialization value in the declaration of a variable, e.g.

real :: a = 0.0

but you have to be careful when such an initialization is performed in a procedure because in that case the initialization is performed only the first time you call the procedure and, in the next, the variable assumes the save attribute. In other words, if the value of a is changed by the end of the first call to the procedure, it has this value (and not zero) at the beginning of the second call.

Code:
program p
implicit none
integer i

do i = 1,10
  call sub1
end do

print*

do i = 1,10
  call sub2
end do

end program p

subroutine sub1
integer :: k = 1
  print*, 'Val of K in sub1', k
  k = k + 1
end subroutine sub1

subroutine sub2
integer :: k
  k = 1
  print*, 'Val of K in sub1', k
  k = k + 1
end subroutine sub2
Back to top
View user's profile Send private message Visit poster's website
Zach



Joined: 13 Mar 2023
Posts: 85
Location: Groningen, Netherlands

PostPosted: Thu May 11, 2023 1:11 am    Post subject: Reply with quote

In my casus as posted
program banana
integer::n
print*,'The Result'
do while(n < 4)
n = n + 1
print*,n
end do
print*
read *
end program banana
There is no initial value to n, but a print below the loop brings out the prints within the loop. This baffles me.
Back to top
View user's profile Send private message Send e-mail
wahorger



Joined: 13 Oct 2014
Posts: 1185
Location: Morrison, CO, USA

PostPosted: Thu May 11, 2023 4:53 am    Post subject: Reply with quote

Zach,

If you wish that FORTRAN was like "C", your wish will never be fulfilled. The rules are different. The syntax is different. Some things are easy to do in FORTRAN, some things are easy to do in "C". I happen to like both for what they can do, and they do work well together!

That being said:
"C" guarantees that static or dynamic (stack) variables are initialized to zero.

FORTRAN does not.

You may find a version/vendor of FORTRAN that does guarantee the value of uninitialized memory, but it is the exception rather than the rule.

Memory that is not intentionally initialized may/will contain any value possible. I am thankful for the compiler messages about using an uninitialized variable; it has saved me numerous times from tracking down bugs due to uninitialized memory issues.

It is simple; if you wish to play in this arena, get used to the rules. Rather than questioning why something appears to work a certain way when you do not obey the rules, abide by the rules, see what happens, and then comment.
Back to top
View user's profile Send private message Visit poster's website
Zach



Joined: 13 Mar 2023
Posts: 85
Location: Groningen, Netherlands

PostPosted: Thu May 11, 2023 9:35 am    Post subject: Reply with quote

Bill, I can understand that Fortran doesn't like uninitialized variables. And that, I shall bear in mind, henceforth. However, you do not seem to have understood my question: rather than assume negative attitudes on my behalf, for which you had no cause. In the case in hand, the compiler, having executed a loop - without printing - depending on the statements that follow the loop, goes back and prints what it didn't print before. That was the issue that I found mind boggling. I think know-why is as important as know-how hence my reluctant rooky question, fearful of harvesting responses like yours.

Last edited by Zach on Thu May 11, 2023 3:22 pm; edited 4 times in total
Back to top
View user's profile Send private message Send e-mail
Kenneth_Smith



Joined: 18 May 2012
Posts: 696
Location: Hamilton, Lanarkshire, Scotland.

PostPosted: Thu May 11, 2023 11:29 am    Post subject: Reply with quote

The behaviour you observe indicates that the memory location the program is using to store the value n was filled with zeros by the program that previously used this location.
Back to top
View user's profile Send private message Visit poster's website
Zach



Joined: 13 Mar 2023
Posts: 85
Location: Groningen, Netherlands

PostPosted: Thu May 11, 2023 1:44 pm    Post subject: Reply with quote

Yes stuff lurking in memory might indeed cause unpleasant surprises, but not, given sequential execution, going back to statements, supposedly already dealt with. Not unless the compiler goes back and forth like a scrubbing brush dealing with several statements at a time.
Back to top
View user's profile Send private message Send e-mail
JohnCampbell



Joined: 16 Feb 2006
Posts: 2538
Location: Sydney

PostPosted: Thu May 11, 2023 3:10 pm    Post subject: Reply with quote

Zach,

Your statement "do while(n < 4)" says that the loop operation is dependent on the initial value of n, so it needs an initial value to get a predictable result.
Depending on what compiler options you provide to FTN95, the initial value of n in your program can be different, especially /undef, /check or /optimise will give significantly different results.

Depending on your compiler option, using "print*" can/could change the initial value of n. As n is undefined, if the (random) initial value of n is >= 4, no print of n value will be given. ( changing the code often results in changes to undefined variable errors )

You may not like a "negative attitude", but failure to provide an initial value of n does not conform to the F95+ standards and so the results from your program are unpredictable.
Back to top
View user's profile Send private message
Kenneth_Smith



Joined: 18 May 2012
Posts: 696
Location: Hamilton, Lanarkshire, Scotland.

PostPosted: Thu May 11, 2023 4:04 pm    Post subject: Reply with quote

Zach,

It is not productive to pursue the question “why”, after it was established that the code is not aligned with the rules of Fortran.

In pursuing this, you are drawing incorrect conclusions from your observations of the program output at runtime and as a consequence making extremely erroneous and misleading statements and speculative claims about the performance of FTN95.

In the context of this relatively simple program there is no issue with FTN95.

When the code follow the rules, and n is explicitly initialised to zero, the code runs correctly with FTN95 Win32, FTN95 X64, gFortran and IFort. This is not the case where n is not explicitly initialised to zero, and this should not be expected (since the code does not follow the rules).

When you compile the code with Checkmate, you can step through the code line by line using the Debugger. You will discover that this exercise confirms the correct serial execution of the code.
Back to top
View user's profile Send private message Visit poster's website
wahorger



Joined: 13 Oct 2014
Posts: 1185
Location: Morrison, CO, USA

PostPosted: Thu May 11, 2023 5:26 pm    Post subject: Reply with quote

Kenneth, thanks for the additional confirmation.

Well put.
Back to top
View user's profile Send private message Visit poster's website
Zach



Joined: 13 Mar 2023
Posts: 85
Location: Groningen, Netherlands

PostPosted: Thu May 11, 2023 8:06 pm    Post subject: Reply with quote

Thank you all for participating in the discussion. Much appreciated. Patrick.
Back to top
View user's profile Send private message Send e-mail
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> General All times are GMT + 1 Hour
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group