|
forums.silverfrost.com Welcome to the Silverfrost forums
|
View previous topic :: View next topic |
Author |
Message |
KennyT
Joined: 02 Aug 2005 Posts: 317
|
Posted: Wed Apr 29, 2015 1:31 pm Post subject: use of LOC function and /UNDEF |
|
|
hi,
we make use of the following unusual syntax (for reasons too complicated to explain here!):
LOC(VARIABLE) = IADDRESS
and it works well, but fails to compile under /undef with the following error:
ERROR 215: Invalid expression on left hand side of assignment
I realise it's an unusual use of the LOC function but we'd still like to be able to compile code with /undef during testing.
K |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7925 Location: Salford, UK
|
Posted: Wed Apr 29, 2015 2:03 pm Post subject: |
|
|
This code looks strange to me.
Can you post a small program that illustrates the context and describe what it should do. |
|
Back to top |
|
|
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2388 Location: Yateley, Hants, UK
|
Posted: Wed Apr 29, 2015 2:17 pm Post subject: |
|
|
Looks to me that you have discovered an improbability overflow: when the improbability is infinite it behaves as infinitely probable - and works!
Putting a function, especially a standard one, on the LHS of an assignment statement can't ever be right - or can it? |
|
Back to top |
|
|
KennyT
Joined: 02 Aug 2005 Posts: 317
|
Posted: Wed Apr 29, 2015 2:35 pm Post subject: |
|
|
ok...
Essentially, we have a routine that stores addresses of variables used in our dialogues thus:
SUBROUTINE SETADDR( ISCREEN, IFIELD, A)
INTEGER IADDRESS(MAXSCR,MAXFLD)
COMMON/BLAH/ IADDRESS
IADDRESS(ISCREEN, IFIELD) = LOC(A)
Then in the dialogue handling code we may want to do some "sense checking" so we reverse the usage:
SUBROUTINE CHECKFIELD (ISCREEN, IFIELD, AMIN, AMAX, IRET)
INTEGER IADDRESS(MAXSCR,MAXFLD)
COMMON/BLAH/ IADDRESS
LOC(A) = IADDRESS(ISCREEN, IFIELD)
IRET = 0
IF( A.LT.AMIN .OR. A.GT.AMAX) THEN
WRITE(*,*) "Entered value outside limits"
IRET = 1
ENDIF
is that enough info?
K |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7925 Location: Salford, UK
|
Posted: Wed Apr 29, 2015 7:47 pm Post subject: |
|
|
Could you supply simpler and complete code.
For example, the following is a working program in a similar context...
Code: | integer iaddress
real a
iaddress = loc(a)
fcore4(iaddress) = 42.0
print*,a
end |
|
|
Back to top |
|
|
davidb
Joined: 17 Jul 2009 Posts: 560 Location: UK
|
Posted: Wed Apr 29, 2015 9:58 pm Post subject: Re: |
|
|
LitusSaxonicum wrote: |
Putting a function, especially a standard one, on the LHS of an assignment statement can't ever be right - or can it? |
Well its clearly nonsense in Fortran 95 though as you see in Paul's post above nonsense is sometimes acceptable. There is a meaning in Python but even there it looks a little weird. Also there is such a syntax in Fortran 2008 but there are not many compilers.
I believe what Kenny T is trying to do is dereference the address. In which case instead of
Code: |
LOC(A) = IADDRESS(ISCREEN, IFIELD)
|
he should use the following
Code: |
A = FCORE4(IADDRESS(ISCREEN, IFIELD))
|
Since FCORE4 is the inverse of LOC.
Kenny T seems to have forgotten about this thread where he posted the same solution in 2013 (if its the same, the one and only Kenny T ) :
https://software.intel.com/en-us/forums/topic/394026 _________________ Programmer in: Fortran 77/95/2003/2008, C, C++ (& OpenMP), java, Python, Perl |
|
Back to top |
|
|
KennyT
Joined: 02 Aug 2005 Posts: 317
|
Posted: Thu Apr 30, 2015 9:59 am Post subject: |
|
|
Here's a complete example with a comment that FCORE4 doesn't do the business:
Code: |
!ftn95$free
MODULE CMAPS
TYPE SCA
REAL :: Y1, Y2
END TYPE SCA
TYPE CMAP
INTEGER :: I1, I2
REAL :: R1, R2
REAL, POINTER :: VALS(:)
TYPE (SCA), POINTER :: SC
END TYPE CMAP
END MODULE CMAPS
PROGRAM NMAP
USE CMAPS
TYPE (CMAP),POINTER :: CM
ALLOCATE (CM, stat=IST)
CM%I1 = 1
CM%I2 = 2
CM%R1 = 10.
CM%R2 = 20.
ALLOCATE (CM%VALS(30), stat=IST)
DO I = 1, 30
CM%VALS(I) = I/2.
END DO
ALLOCATE (CM%SC)
CM%SC%Y1 = 0.
CM%SC%Y2 = 1.
IAD = loc(CM)
CALL FUDGEIT (IAD)
END PROGRAM
SUBROUTINE FUDGEIT (IAD)
USE CMAPS
TYPE (CMAP), POINTER :: CM
NN = 3
loc(CM) = IAD
N = size(CM%VALS)
WRITE (*,*) CM%I1, CM%I2, CM%R1, CM%R2, N
WRITE (*,*) (CM%VALS(J),J=1,N,5)
WRITE (*,*) CM%SC%Y1, CM%SC%Y2
! CM = fcore4(IAD) ! wont compile
END SUBROUTINE FUDGEIT |
Some more detail as to the thinking behind what is going on:
We have a linked list structure which we want to use with different models. The basic model has some scalars and vectors, but in some circumstances we want to add stuff to it – in other words, change the model. The example is a (basic version) of a colour map which describes how to plot the data. But in a different context we might want a file name or a regression result, each another derived type pointer. If we can reference these through their address and access via loc() we don’t have to have a different linked list structure (and all its associated code) for each variant.
K |
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1886
|
Posted: Thu Apr 30, 2015 12:58 pm Post subject: |
|
|
Uncompilable code snippets with the author's own assessment of what the code is doing (or what it is not doing) are problematic. Here is a slight modification of the subroutine above http://forums.silverfrost.com/posting.php?mode=quote&p=18057
Code: | SUBROUTINE CHECKFIELD (ISCREEN, IFIELD, AMIN, AMAX, IRET)
integer, parameter :: maxscr=25, maxfld=80
INTEGER IADDRESS(MAXSCR,MAXFLD)
COMMON/BLAH/ IADDRESS
LOC(A) = IADDRESS(ISCREEN, IFIELD)
IRET = 0
IF( A.LT.AMIN .OR. A.GT.AMAX) THEN
WRITE(*,*) "Entered value outside limits"
IRET = 1
ENDIF
end subroutine |
The only modification is the declaration of the parameters used in the array declaration, without which the code is not valid. For the modified code, FTN95 clearly says what it thinks:
Code: | [FTN95/Win32 Ver. 7.10.0 Copyright (c) Silverfrost Ltd 1993-2014]
0005) LOC(A) = IADDRESS(ISCREEN, IFIELD)
COMMENT - This statement function definition for LOC hides the intrinsic routine of the same name
NO ERRORS, 1 COMMENT [<CHECKFIELD> FTN95/Win32 v7.10.0] |
Placed just after the variable declarations, the line containing LOC is taken as an ASF definition. The selection of the name of the ASF to be the same as the name of a standard function (or nonstandard but common extension, as with LOC) is the source of much confusion. What is in a name? |
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1886
|
Posted: Thu Apr 30, 2015 12:58 pm Post subject: |
|
|
Uncompilable code snippets with the author's own assessment of what the code is doing (or what it is not doing) are problematic. Here is a slight modification of the subroutine above http://forums.silverfrost.com/posting.php?mode=quote&p=18057
Code: | SUBROUTINE CHECKFIELD (ISCREEN, IFIELD, AMIN, AMAX, IRET)
integer, parameter :: maxscr=25, maxfld=80
INTEGER IADDRESS(MAXSCR,MAXFLD)
COMMON/BLAH/ IADDRESS
LOC(A) = IADDRESS(ISCREEN, IFIELD)
IRET = 0
IF( A.LT.AMIN .OR. A.GT.AMAX) THEN
WRITE(*,*) "Entered value outside limits"
IRET = 1
ENDIF
end subroutine |
The only modification is the declaration of the parameters used in the array declaration, without which the code is not valid. For the modified code, FTN95 clearly says what it thinks:
Code: | [FTN95/Win32 Ver. 7.10.0 Copyright (c) Silverfrost Ltd 1993-2014]
0005) LOC(A) = IADDRESS(ISCREEN, IFIELD)
COMMENT - This statement function definition for LOC hides the intrinsic routine of the same name
NO ERRORS, 1 COMMENT [<CHECKFIELD> FTN95/Win32 v7.10.0] |
Placed just after the variable declarations, the line containing LOC is taken as an ASF definition. The selection of the name of the ASF to be the same as the name of a standard function (or nonstandard but common extension, as with LOC) is the source of much confusion. What is in a name? |
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1886
|
Posted: Thu Apr 30, 2015 12:59 pm Post subject: |
|
|
Uncompilable code snippets with the author's own assessment of what the code is doing (or what it is not doing) are problematic. Here is a slight modification of the subroutine above http://forums.silverfrost.com/posting.php?mode=quote&p=18057
Code: | SUBROUTINE CHECKFIELD (ISCREEN, IFIELD, AMIN, AMAX, IRET)
integer, parameter :: maxscr=25, maxfld=80
INTEGER IADDRESS(MAXSCR,MAXFLD)
COMMON/BLAH/ IADDRESS
LOC(A) = IADDRESS(ISCREEN, IFIELD)
IRET = 0
IF( A.LT.AMIN .OR. A.GT.AMAX) THEN
WRITE(*,*) "Entered value outside limits"
IRET = 1
ENDIF
end subroutine |
The only modification is the declaration of the parameters used in the array declaration, without which the code is not valid. For the modified code, FTN95 clearly says what it thinks:
Code: | [FTN95/Win32 Ver. 7.10.0 Copyright (c) Silverfrost Ltd 1993-2014]
0005) LOC(A) = IADDRESS(ISCREEN, IFIELD)
COMMENT - This statement function definition for LOC hides the intrinsic routine of the same name
NO ERRORS, 1 COMMENT [<CHECKFIELD> FTN95/Win32 v7.10.0] |
Placed just after the variable declarations, the line containing LOC is taken as an ASF definition. The selection of the name of the ASF to be the same as the name of a standard function (or nonstandard but common extension, as with LOC) is the source of much confusion. What is in a name? |
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1886
|
Posted: Thu Apr 30, 2015 1:01 pm Post subject: |
|
|
Sorry about the multiple "replies". The forum server replied "Debug Mode, try submitting later", which I did.
Here is a screenshot:
https://www.dropbox.com/s/4cot0e0aih0si0z/dbgmode.png?dl=0
MODERATOR: Please keep the first copy and delete the rest, and delete this apology.
Last edited by mecej4 on Thu Apr 30, 2015 1:24 pm; edited 1 time in total |
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1886
|
Posted: Thu Apr 30, 2015 1:06 pm Post subject: |
|
|
Sorry about the multiple "replies". The forum server replied "Debug Mode, try submitting later", which I did. Here is a screenshot:
https://www.dropbox.com/s/4cot0e0aih0si0z/dbgmode.png?dl=0
MODERATOR: Please keep the first copy and delete the rest, and delete this apology. |
|
Back to top |
|
|
JohnCampbell
Joined: 16 Feb 2006 Posts: 2554 Location: Sydney
|
Posted: Thu Apr 30, 2015 1:07 pm Post subject: |
|
|
Kenny,
I am struggling to understand your problem.
I think you could use an expression like "cm%r1 = fcore4(IAD)" for a real*4 component of type (CMAP), but not equating a real*4 value to a type(CMAP) CM.
All the core intrinsic functions are effective virtual arrays of the memory for the intrinsic data types. They are effectively arrays, whose argument is the memory byte address and can be used as arrays on either the left or right of =.
Also, your use of loc (CM) also has problems, as you can not guarantee the order and placement of intrinsic data types within the CMAP structure. All that " = fcore4(IAD)" provides is the 4 bytes, starting from memory address IAD, as a real*4 variable.
You would need to develop a type (CMAP) function CMAP CORE N, that transfers the n bytes of the CMAP structure, starting from memory byte address IAD, but again, I don't think you can make assumptions of the byte order of intrinsic variables within the TYPE (CMAP).
Is this what you are trying to do ?
John |
|
Back to top |
|
|
KennyT
Joined: 02 Aug 2005 Posts: 317
|
Posted: Thu Apr 30, 2015 3:31 pm Post subject: |
|
|
I'll reply with more detail later.
note to the mods:
i've checked the "notify me" box but, after the initial notification of the first reply from Paul, i'm no longer getting the emails? (which is why i didn't reply earlier!)
K |
|
Back to top |
|
|
John-Silver
Joined: 30 Jul 2013 Posts: 1520 Location: Aerospace Valley
|
Posted: Thu Apr 30, 2015 4:14 pm Post subject: |
|
|
I've been having the same problem as mecej4 with the same error message he got.
This happens from time to time I've noticed and usually a quick check and you'll find the post has actually been done OK !!!!! (so no need then to re-post).
... but its still very annoying. |
|
Back to top |
|
|
|
|
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
|