- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Link Copied
9 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Well, it's probably accepted by the compiler, but likely doesn't do what you want. It is not legal in standard Fortran because (10
Rewriting this to something more likely would be:
if ((10 < i) .and. (i < 20))
Rewriting this to something more likely would be:
if ((10 < i) .and. (i < 20))
Message Edited by sblionel on 03-15-2005 12:40 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Ok.
As written in "International Standard programming language Fortran" by J3:
"An intrinsic binary operation is an operation of the form x1 intrinsic-operator x2 where x1 and
x2 are of the intrinsic types (4.4) listed in Table 7.1 for the binary intrinsic operator :"
And later:
"A numeric relational intrinsic operation is a relational intrinsic operation where the operands are of numeric type. A character relational intrinsic operation is a relational intrinsic operation where
the operands are of type character."
So, in prev. example the second relational operation ((10
As written in "International Standard programming language Fortran" by J3:
"An intrinsic binary operation is an operation of the form x1 intrinsic-operator x2 where x1 and
x2 are of the intrinsic types (4.4) listed in Table 7.1 for the binary intrinsic operator :"
And later:
"A numeric relational intrinsic operation is a relational intrinsic operation where the operands are of numeric type. A character relational intrinsic operation is a relational intrinsic operation where
the operands are of type character."
So, in prev. example the second relational operation ((10
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Sorry, it is continuation:)
So, in prev. example the second relational operation ((10
So, in prev. example the second relational operation ((10
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Ok.
As written in "International Standard programming language Fortran" by J3:
"An intrinsic binary operation is an operation of the form x1 intrinsic-operator x2 where x1 and
x2 are of the intrinsic types (4.4) listed in Table 7.1 for the binary intrinsic operator :"
And later:
"A numeric relational intrinsic operation is a relational intrinsic operation where the operands are of numeric type. A character relational intrinsic operation is a relational intrinsic operation where
the operands are of type character."
So, in prev. example the second relational operation
As written in "International Standard programming language Fortran" by J3:
"An intrinsic binary operation is an operation of the form x1 intrinsic-operator x2 where x1 and
x2 are of the intrinsic types (4.4) listed in Table 7.1 for the binary intrinsic operator :"
And later:
"A numeric relational intrinsic operation is a relational intrinsic operation where the operands are of numeric type. A character relational intrinsic operation is a relational intrinsic operation where
the operands are of type character."
So, in prev. example the second relational operation
((10 < i) < 20)is illegal, as you write: "It is not legal in standard Fortran". For my opinion, compiler should tell me about it. Am i right?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
If you ask it to do so, yes:
c:Myprojects>ifort /stand t.f90
Intel Fortran Compiler for 32-bit applications, Version 8.1 Build 20050201Z Package ID: w_fc_pc_8.1.028
Copyright (C) 1985-2005 Intel Corporation. All rights reserved.
t.f90(2) : Warning: Fortran 95 does not allow this data type conversion.
if (10 < i < 20) j = 4
-------^
Actually, I've been lobbying to make the compiler less forgiving on this sort of conversion, but it has a very long history (30 years or more).
c:Myprojects>ifort /stand t.f90
Intel Fortran Compiler for 32-bit applications, Version 8.1 Build 20050201Z Package ID: w_fc_pc_8.1.028
Copyright (C) 1985-2005 Intel Corporation. All rights reserved.
t.f90(2) : Warning: Fortran 95 does not allow this data type conversion.
if (10 < i < 20) j = 4
-------^
Actually, I've been lobbying to make the compiler less forgiving on this sort of conversion, but it has a very long history (30 years or more).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
All right. Thank you Steve :)))))
I was sure that the reason is long historical "tail" of FORTRAN. And i agree with you, that Fortran must eliminate such ... inconsistency, gap, "ear" of history.
By what reason CVF allow that expression? I try gfortran and it show me the error (not warning!).
migmile
I was sure that the reason is long historical "tail" of FORTRAN. And i agree with you, that Fortran must eliminate such ... inconsistency, gap, "ear" of history.
By what reason CVF allow that expression? I try gfortran and it show me the error (not warning!).
migmile
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
It is DEC Fortran history that "free conversion" between LOGICAL and numeric types is allowed. The value you get is the binary form of the LOGICAL value interpreted as a signed integer. .FALSE. is zero and .TRUE. is -1 (unless you have selected /fpscomp:logicals, in which case .TRUE. is +1). This is documented in the Language Reference Manual.
This extension was widely taken advantage of on VMS, where routines that returned an integer status could be tested as if they were logicals - success statuses tested as true and error statuses tested as false. If it were only the conversion of integer to logical, that might not be so bad, but, as you found, logicals get free conversion to integer or even real and complex, with bizarre results.
Another place people run into this is list-directed input, where T and F are accepted for numeric input. These are interpreted as .TRUE. and .FALSE. and converted according to the documented rules. I doubt anyone really depends on this behavior, though, and it has been the cause of many complaints over the years.
Newer compilers that don't have the generous history of the DEC-heritage compilers tend to leave out such extensions, often with good reason. It is a "pet project" of mine to get our compilers to at least warn you about such usage by default.
This extension was widely taken advantage of on VMS, where routines that returned an integer status could be tested as if they were logicals - success statuses tested as true and error statuses tested as false. If it were only the conversion of integer to logical, that might not be so bad, but, as you found, logicals get free conversion to integer or even real and complex, with bizarre results.
Another place people run into this is list-directed input, where T and F are accepted for numeric input. These are interpreted as .TRUE. and .FALSE. and converted according to the documented rules. I doubt anyone really depends on this behavior, though, and it has been the cause of many complaints over the years.
Newer compilers that don't have the generous history of the DEC-heritage compilers tend to leave out such extensions, often with good reason. It is a "pet project" of mine to get our compilers to at least warn you about such usage by default.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thank you Steve! Very interesting history!
I now about conversion from LOGICAL to INTEGER, but dont now reasons.
But look, all program languages are developed in one direction - to protect programmer from making errors. And FORTRAN with his "rich history" permits to make VERY MANY errors, especially for beginners.
migmile
I now about conversion from LOGICAL to INTEGER, but dont now reasons.
But look, all program languages are developed in one direction - to protect programmer from making errors. And FORTRAN with his "rich history" permits to make VERY MANY errors, especially for beginners.
migmile
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
It is very common to mix integers and logicals. For example, programs do things such as (I .AND. J) where I and J are integers, expecting "bitwise AND", even though the .AND. operator is a "logical AND" which need produce only two distinct values, .TRUE. and .FALSE..
See an article I wrote a while back for more on this.

Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page