Part of a code in a Fortran project that I am trying to compile is
implicit double precision (a-h,o-z)
dimension fact(1:5)
data fact /
d660p=rpt1*dp(6,beta2,rpt1)*d3(0,6,0,beta2,rpt1,rpt2,rpt3)
1 +rpt2*dp(6,beta2,rpt2)*d3(6,0,0,beta2,rpt1,rpt2,rpt3)
d606p=rpt1*dp(6,beta2,rpt1)*d3(0,0,6,beta2,rpt1,rpt2,rpt3)
1 +rpt3*dp(6,beta2,rpt3)*d3(6,0,0,beta2,rpt1,rpt2,rpt3)
d066p=rpt2*dp(6,beta2,rpt2)*d3(0,0,6,beta2,rpt1,rpt2,rpt3)
1 +rpt3*dp(6,beta2,rpt3)*d3(0,6,0,beta2,rpt1,rpt2,rpt3)
d633p=rpt1*dp(6,beta3,rpt1)*d3(0,3,3,beta3,rpt1,rpt2,rpt3)
1 +rpt2*dp(3,beta3,rpt2)*d3(6,0,3,beta3,rpt1,rpt2,rpt3)
1 +rpt3*dp(3,beta3,rpt3)*d3(6,3,0,beta3,rpt1,rpt2,rpt3)
d363p=rpt1*dp(3,beta3,rpt1)*d3(0,6,3,beta3,rpt1,rpt2,rpt3)
1 +rpt2*dp(6,beta3,rpt2)*d3(3,0,3,beta3,rpt1,rpt2,rpt3)
1 +rpt3*dp(3,beta3,rpt3)*d3(3,6,0,beta3,rpt1,rpt2,rpt3)
d336p=rpt1*dp(3,beta3,rpt1)*d3(0,3,6,beta3,rpt1,rpt2,rpt3)
1 +rpt2*dp(3,beta3,rpt2)*d3(3,0,6,beta3,rpt1,rpt2,rpt3)
1 +rpt3*dp(6,beta3,rpt3)*d3(3,3,0,beta3,rpt1,rpt2,rpt3)/
however, compiling generates the following errors
mc.f(2003): error #5082: Syntax error, found END-OF-STATEMENT when expecting one of: ( <IDENTIFIER> <CHAR_CON_KIND_PARAM> <CHAR_NAM_KIND_PARAM> <CHARACTER_CONSTANT> <INTEGER_CONSTANT> ...
data fact /
------------------^
mc.f(2018): error #5082: Syntax error, found END-OF-STATEMENT when expecting one of: ( <IDENTIFIER> <CHAR_CON_KIND_PARAM> <CHAR_NAM_KIND_PARAM> <CHARACTER_CONSTANT> <INTEGER_CONSTANT> ...
1 +rpt3*dp(8,beta8,rpt3)*d3(0,6,0,beta8,rpt1,rpt2,rpt3) /
------------------------------------------------------------------^
compilation aborted for mc.f (code 1)
Does anybody knows how to get the code working?
The syntax error you get is because data fact / is on a line on its own with nothing after the opening slash. The compiler expects a constant or parameter name and tells you so. As is, the data statement is incomplete. (Thanks for High Performance Mark for pointing this out. I missed this in my earlier answer.)
You can make the compiler treat whole data statement up to the closing slash as a single line by using the continuation mark on every line after the data line. Your continuations continue only the expressions inside the data. (And the items inside datashould be separated by commas.)
Fixing the continuation and the commas will not make the code compile, though.
The data statement initialises variables when the program starts. The numbers between the slashes must therefore be constants or named parameters. You cannot use expressions, not even expressions on constants. (The expression 3*0.0 has a special meaning inside data; it means three times the value zero, i.e. 0.0, 0.0, 0.0.)
If you want to initialise your array, use assignments, which will calculate the entries based on the current value of the variables:
fact(1) = rpt1*dp(6,beta2,rpt1)*d3(0,6,0,beta2,rpt1,rpt2,rpt3)
1 + rpt2*dp(6,beta2,rpt2)*d3(6,0,0,beta2,rpt1,rpt2,rpt3)
or, if you also need the intermediary variables:
d660p = rpt1*dp(6,beta2,rpt1)*d3(0,6,0,beta2,rpt1,rpt2,rpt3)
1 + rpt2*dp(6,beta2,rpt2)*d3(6,0,0,beta2,rpt1,rpt2,rpt3)
fact(1) = d660p
By the way, your array has five entries, but you are trying to initialise six. And implicit variable naming isn't a good idea either.
Related
I am getting the following errors/warnings:
WARNING: Apparent symbolic reference ARRAY_MONTH_COUNT not resolved.
ERROR: Too many variables defined for the dimension(s) specified for the array array1.
ERROR 22-322: Syntax error, expecting one of the following: an integer constant, *.
ERROR 200-322: The symbol is not recognized and will be ignored.
for the following code:
data demo_effective;
set work.demo;
array array1 [&array_month_count] $ 1 membsdemo_flag_&start_yrmo
membsdemo_flag_&end_yrmo;
length yrmo 6;
do i=1 to &array_month_count;
if array1[i] = 'N' then continue;
if array1[i] = 'Y' then yrmo = substrn(vname(array1[i]),20,6);
output;
end;
run;
I didn't write this program, I am just trying to work with it, so I don't know why this isn't working (I made no changes, just ran the program in SAS and it was already broken), and I am still learning SAS and SQL, so half of this program is nonsense to me even after watching some videos and trying to find more information about it.
If it helps, it looks like the warning/errors are occurring around array1 [&array_month_count].
&array_month_count is a macro variable. In SAS, this is a string that is substituted at compile time. Macros "write" code.
It looks like all the errors you are getting are because that variable does not have a value.
So somewhere in the code, there should be something that sets the value of array_month_count. Find that, fix it, and this step should work.
A bit more detail than Dom's answer may be helpful, though his answer is certainly the crux of the issue.
&array_month_count needs to be defined, but you also probably have a few other issues.
array array1 [&array_month_count] $ 1 membsdemo_flag_&start_yrmo
membsdemo_flag_&end_yrmo;
This is probably wrong, or else this code is perhaps doing something different from what it used to: I suspect it is intended to be
array array1 [&array_month_count] $ 1 membsdemo_flag_&start_yrmo - membsdemo_flag_&end_yrmo;
In other words, it's probably supposed to expand to something like this.
array array1 [6] $ 1 membsdemo_flag_1701 membsdemo_flag_1702 membsdemo_flag_1703 membsdemo_flag_1704 membsdemo_flag_1705 membsdemo_flag_1706;
The 6 there isn't actually needed since the variables are listed out (in a condensed form). The dash tells SAS to expand numerically with consecutive numbers from the start to the end; it would only work if your yrmo never crosses a year boundary. It's possible -- is appropriate instead - it tells SAS to expand in variable number order, which works fine if you have consecutively appearing variables (in other words, they're adjacent when you open the dataset).
The 6 is however needed for the second bit.
do i=1 to &array_month_count;
Unless you rewrite it to this:
do i = 1 to dim(array1); *dim = dimension, or count of variables in that array;
In which case you really don't even need that value.
--
If it's actually intended to be the code as above, and only have 2 variables, then you don't need &array_month_count since it's known to be only 2 variables.
I am writing the following simple routine:
program scratch
character*4 :: word
word = 'hell'
print *, concat(word)
end program scratch
function concat(x)
character*(*) x
concat = x // 'plus stuff'
end function concat
The program should be taking the string 'hell' and concatenating to it the string 'plus stuff'. I would like the function to be able to take in any length string (I am planning to use the word 'heaven' as well) and concatenate to it the string 'plus stuff'.
Currently, when I run this on Visual Studio 2012 I get the following error:
Error 1 error #6303: The assignment operation or the binary
expression operation is invalid for the data types of the two
operands. D:\aboufira\Desktop\TEMP\Visual
Studio\test\logicalfunction\scratch.f90 9
This error is for the following line:
concat = x // 'plus stuff'
It is not apparent to me why the two operands are not compatible. I have set them both to be strings. Why will they not concatenate?
High Performance Mark's comment tells you about why the compiler complains: implicit typing.
The result of the function concat is implicitly typed because you haven't declared its type otherwise. Although x // 'plus stuff' is the correct way to concatenate character variables, you're attempting to assign that new character object to a (implictly) real function result.
Which leads to the question: "just how do I declare the function result to be a character?". Answer: much as you would any other character variable:
character(len=length) concat
[note that I use character(len=...) rather than character*.... I'll come on to exactly why later, but I'll also point out that the form character*4 is obsolete according to current Fortran, and may eventually be deleted entirely.]
The tricky part is: what is the length it should be declared as?
When declaring the length of a character function result which we don't know ahead of time there are two1 approaches:
an automatic character object;
a deferred length character object.
In the case of this function, we know that the length of the result is 10 longer than the input. We can declare
character(len=LEN(x)+10) concat
To do this we cannot use the form character*(LEN(x)+10).
In a more general case, deferred length:
character(len=:), allocatable :: concat ! Deferred length, will be defined on allocation
where later
concat = x//'plus stuff' ! Using automatic allocation on intrinsic assignment
Using these forms adds the requirement that the function concat has an explicit interface in the main program. You'll find much about that in other questions and resources. Providing an explicit interface will also remove the problem that, in the main program, concat also implicitly has a real result.
To stress:
program
implicit none
character(len=[something]) concat
print *, concat('hell')
end program
will not work for concat having result of the "length unknown at compile time" forms. Ideally the function will be an internal one, or one accessed from a module.
1 There is a third: assumed length function result. Anyone who wants to know about this could read this separate question. Everyone else should pretend this doesn't exist. Just like the writers of the Fortran standard.
I'm attempting to modernize an old code (or at least make it a bit more understandable) but I've run into an odd format for a, uh, FORMAT statement.
Specifically, it's a FORMAT statement with Hollerith constants in it (the nH where n is a number):
FORMAT(15H ((C(I,J),J=1,I3,12H),(D(J),J=1,I3, 6H),I=1,I3,') te'
1,'xt' )
This messes with the syntax highlighting as it appears this has unclosed parenthesis. It compiles fine with this format statement as is, but closing the parenthesis causes a compiling error (using either the intel or gfortran compiler).
As I understand it, Hollerith constants were a creature of Fortran 66 and were replaced with the advent of the CHARACTERin Fortran 77. I generally understand them when used as something like a character, but use as a FORMAT confuses me.
Further, if I change 15H ((... to 15H ((... (i.e. I remove one space) it won't compile. In fact, it won't compile even if I change the code to this:
FORMAT(15H ((C(I,J),J=1,I3,12H),(D(J),J=1,I3, 6H),I=1,I3,') text' )
I would like this to instead be in a more normal (F77+) format. Any help is appreciated.
What you have are actually Hollerith edit descriptors, not constants (which would occur in a DATA or CALL statement), although they use the same syntax. F77 replaced Hollerith constants outright; it added char-literal edit descriptor as a (much!) better alternative, but H edit descriptor remained in the standard until F95 (and even then some compilers still accepted it as a compatibility feature).
In any case, the number before the H takes that number of characters after the H, without any other delimiter; that's why deleting (or adding) a character after the H screws it up. Parsing your format breaks it into these pieces
15H ((C(I,J),J=1,
I3,
12H),(D(J),J=1,
I3,
6H),I=1,
I3,
') te'
'xt'
and thus a modern equivalent (with optional spaces for clarity) is
nn FORMAT( ' ((C(I,J),J=1,', I3, '),(D(J),J=1,', I3, '),I=1,', I3
1,') text' )
or if you prefer you can put that text after continuation (including the parens) in a CHARACTER value, variable or parameter, used in the I/O statement instead of a FORMAT label, but since you must double all the quote characters to get them in a CHARACTER value that's less convenient.
Your all-on-one-line version probably didn't compile because you were using fixed-form, perhaps by default, and only the first 72 characters of each source line are accepted in fixed-form, of which the first 6 are reserved for statement number and continuation indicator, leaving only 66 and that statement is 71 by my count. Practically any compiler you will find today also accepts free-form, which allows longer lines and has other advantages too for new code, but may require changes in existing code, sometimes extensive changes.
Hi I am new here and want to solve this problem:
do k=1,31
Data H(1,k)/0/
End do
do l=1,21
Data H(l,1)/0.5*(l-1)/
End do
do m=31,41
Data H(17,m)/0/
End do
do n=17,21
Data H(n,41)/0.5*(n-17)/
End do
I get error for l and n saying that it is a syntax error in DATA statement. Anyone know how to solve this problem?
You have three problems here, and not just with the "l" and "n" loops.
The first problem is that the values in a data statement cannot be arbitrary expressions. In particular, they must be constants; 0.5*(l-1) is not a constant.
The second problem is that the bounds in the object lists must also be constant (expressions); l is not a constant expression.
For the first, it's also worth noting that * in a data value list has a special meaning, and it isn't the multiplication operator. * gives a repeat count, and a repeat count of 0.5 is not valid.
You can fix the second point quite simply, by using such constructions as
data H(1,1:31) /31*0./ ! Note the repeat count specifier
outside a loop, or using an implied loop
data (H(1,k),k=1,31) /31*0./
To do something for the "l" loop is more tedious
data H(1:21,1) /0., 0.5, 1., 1.5, ... /
and we have to be very careful about the number of values specified. This cannot be dynamic.
The third problem is that you cannot specify explicit initialization for an element more than once. Look at your first two loops: if this worked you'd be initializing H(1,1) twice. Even though the same value is given, this is still invalid.
Well, actually you have four problems. The fourth is related to the point about dynamic number of values. You probably don't want to be doing explicit initialization. Whilst it's possible to do what it looks like you want to do, just use assignment where these restrictions don't apply.
do l=1,21
H(l,1) = 0.5*(l-1)
End do
Yes, there are times when complicated explicit initialization is a desirable thing, but in this case, in what I assume is new code, keeping things simple is good. An "initialization" portion of your code which does the assignments is far more "modern".
I'm trying to get some code compiled under gfortran that compiles fine under g77. The problem seems to be from a return statement:
ffuncs.f:934.13:
RETURN E
1
Error: Alternate RETURN statement at (1) requires a SCALAR-INTEGER return specifier
In the code anything E was specified as real*8:
IMPLICIT REAL*8 ( A - H , O -Z )
However, E was never given a value or anything in fact you never see it until the return statement. I know almost nothing about fortran. What is the meaning of a return statement with an argument in fortran?
Thanks.
In FORTRAN (up to Fortran 77, which I'm very familiar with), RETURN n is not used to return a function value; instead, it does something like what in other languages would be handled by an exception: An exit to a code location other than the normal one.
You'd normally call such a SUBROUTINE or FUNCTION with labels as arguments, e.g.
CALL MYSUB(A, B, C, *998, *999)
...
998 STOP 'Error 1'
998 STOP 'Error 2'
and if things go wrong in MYSUB then you do RETURN 1 or RETURN 2 (rather than the normal RETURN) and you'd be hopping straight to label 998 or 999 in the calling routine.
That's why normally you want an integer on that RETURN - it's not a value but an index to which error exit you want to take.
RETURN E sounds wrong to me. Unless there's a syntax I'm unaware of, the previous compiler should have flagged that as an error.
In a Fortran function one returns the value, by assigning the value to a fake variable which is the same name as the function. Once you do that, simply return.
I think #Carl Smotricz has the answer. Does argument list of ffuncs has dummy arguments that are asterisks (to match the asterisk-label in the calls)? Or was this used without there being alternative returns? If there were no alternative returns, just delete the "E". If there are alternative returns, the big question is what the program was doing before at run time since the variable was of the wrong type and uninitialized. If the variable didn't have an integer value matching one of the expected branches, perhaps the program took the regular return branch -- but that's just a guess -- if so, the easy fix is to again to delete the "E".
The "alternate return" feature is considered "obsolescent" by the language standard and could be deleted in a future standard; compilers would likely continue to support it if it were removed because of legacy code. For new code, one simple alternative is to return an integer status variable and use a "select case" statement in the caller.