replica nfl jerseysreplica nfl jerseyssoccer jerseyreplica nfl jerseys forums.silverfrost.com :: View topic - INTEGER(KIND=4) expressions cannot be in logical expressions
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 

INTEGER(KIND=4) expressions cannot be in logical expressions

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



Joined: 10 Mar 2008
Posts: 2923
Location: South Pole, Antarctica

PostPosted: Sat Aug 11, 2012 8:44 am    Post subject: INTEGER(KIND=4) expressions cannot be in logical expressions Reply with quote

Got this diagnostics above in this line where all variables are integer

if(ang_k10.gt.0 .and. ncnf.gt.ang_k10) then

or in the lines like this one i get shocking diagnostics pushing me to do logical comparison

if(ang_k10.eq.0) then

*** The condition in an IF statement should be LOGICAL


Yes, ang_k10 is INTEGER(KIND=4) but why we can not compare integer numbers?
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 8211
Location: Salford, UK

PostPosted: Sun Aug 12, 2012 7:51 am    Post subject: Reply with quote

The following test runs OK for me. Note that kind = 4 will give 64 bit integers unless you use /alt_kinds.

Code:
program LL
integer(kind=4) ang_k10,ncnf
ang_k10 = 0
ncnf = 1
if(ang_k10.eq.0)then
  print*, "OK1"
endif
ang_k10 = 1
ncnf = 2
if(ang_k10.gt.0 .and. ncnf.gt.ang_k10) then
  print*, "OK2"
endif 
end
Back to top
View user's profile Send private message AIM Address
DanRRight



Joined: 10 Mar 2008
Posts: 2923
Location: South Pole, Antarctica

PostPosted: Sun Aug 12, 2012 8:10 am    Post subject: Reply with quote

Paul,
Thanks for looking at this witchcraft. That why i am saying - its shocking...I really do not know what's to do...

BTW, your example works with both cases with and without /alt_kinds, and the code i am trying to use gives also the same diagnostics with and w/o /alt_kinds
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 8211
Location: Salford, UK

PostPosted: Sun Aug 12, 2012 8:19 am    Post subject: Reply with quote

Maybe the problem is some where else.

First try commenting out the offending lines to see what happens.
Back to top
View user's profile Send private message AIM Address
JohnCampbell



Joined: 16 Feb 2006
Posts: 2615
Location: Sydney

PostPosted: Mon Aug 13, 2012 3:21 am    Post subject: Reply with quote

Dan,

This and your other post show code that was written assuming the value of KIND is fixed, which works with most other compilers that share the same KIND assumptions, but not FTN95.
There are two areas that cause problems with this:
1) Declaring variables, eg REAL (8) or INTEGER(4) : The easiest portable solution is to use REAL*8 and INTEGER*4. I forget the long winded standard conforming syntax, which is usually placed in a module, in another file, that later is not listed with the file being compiled.
2) Constants, such as 1.2_8, or in the case of FTN95 1.2_3 for real*10 constants. The easiest way I know to easily solve this is to use parameter definition of constants. Integer*8 and Real*10 always pose problems here. Eg, what is 2_4 ?

Unfortunately this problem was introduced in the late 80's when the standard said the value of KIND was system dependent. Unfortunately FTN95 did not adopt the byte count value and the problem has remained.
My exerience with /alt_kinds was that it did not work with constants. That was a long time ago, so I moved to alternative syntax and haven't tried again.

Again, my recomendation is don't waste your time with the KIND syntax and use the REAL*8 and INTEGER*4 syntax which always works. (There is probably some compiler out there that objects, but I haven't found it.)

Just thought of a new problem area: With 64-bit there is a transition from INTEGER*4 to INTEGER*8 for a number of variables being used, relating to memory address and array size (LOC is now INTEGER*8 for the memory address above 2gb, which works well with FTN95)

John
Back to top
View user's profile Send private message
DanRRight



Joined: 10 Mar 2008
Posts: 2923
Location: South Pole, Antarctica

PostPosted: Mon Aug 13, 2012 8:46 am    Post subject: Reply with quote

How about making this syntax like REAL(Cool INTEGER(4) default? All use it.
Back to top
View user's profile Send private message
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