I have an old Fortran 77 code, which I would like to run in a F90-Compiler, and my goal is to change the code as less as possible. It works quite well, but I have some problem with format statements in the code. And I don't understand what's the problem. I work with Eclipse, and gfortran. I use free form.
Question 1
This compiles fine:
program HelloWorld
400 FORMAT(7HK GAMMA,2X,G13.5,7H P0,2X,G13.5,6H A1,2X,G13.5)
end program
This doesn't compile
program HelloWorld
400 FORMAT(7HK 'GAMMA',2X,G13.5,7H 'P0',2X,G13.5,6H 'A1',2X,G13.5)
1
end program
The Error is
P descriptor needs leading scale factor in format string at (1)
(the error is translated from german, might not be exactly the same words in english) What is wrong?
Question 2
This also compiles fine:
program HelloWorld
400 FORMAT(7HK GAMMA,2X,G13.5,7H P0, &
2X,G13.5,6H A1,2X,G13.5)
end program
If I add more code to the last code:
program HelloWorld
400 FORMAT(7HK GAMMA,2X,G13.5,7H P0,2X,G13.5,6H A1,2X,G13.5, &
2X,7HK,ALPHA-1,2X,G13.5,7H BETA-4,2X,G13.5 )
end program
it doesn't compile anymore. The error is:
P Edit descriptor expected in the format string* at (1)
whereas the (1) is placed at the third line after the closing bracket.
*I'm not sure about the translation of "format string", as my console is in german.
What is the problem there?
Your format statements have an H (for Hollerith) edit descriptors - the things in the format statements that have a number followed immediate by a H. The descriptor results in the characters (including blanks) following the H and counted by the leading number being output to the file.
This language feature was made obsolescent in Fortran 90 and removed completely from the language in Fortran 95.
They are very error prone. Since Fortran 77 a far better way of achieving the same result has been to use character constant edit descriptors.
The problem is that you have (or are creating) a mismatch between the number of characters indicated by the leading number and the actual count of characters that apparently were in the descriptor. For example, your second FORMAT statement is copied below, showing the seven characters that would be in the descriptor. You can see how that appears to end in the middle of a "string". This then confuses what the compiler sees for the remainder of the format specification.
400 FORMAT(7HK 'GAMMA',2X,G13.5,7H 'P0',2X,G13.5,6H 'A1',2X,G13.5)
1234567
As I write in the comment it looks more like FORTRAN66 than 77 because the Hollerith H descriptor and data type was used before introducing the CHARACTER data type to the language. It was also used to assign character data to integer variables, but fortunately that is very rare to encounter. The use as an edit descriptor is however more common, although very obsolete.
It is not clear what you want to achieve, good example of the desired output would be helpful.
Do you meant:
400 FORMAT(7HK GAMMA,2X,G13.5,3H P0,2X,G13.5,3H A1,2X,G13.5)
so that
print 400, 1. ,2. ,3.
outputs
K GAMMA 1.0000 P0 2.0000 A1 3.0000
Or should the P0 and A1 serve as edit descriptors?
What was the original code in the legacy software?
The nH Hollerith descriptor just outputs n next characters so it can unintentionally "eat" some of your descriptors and just print them.
That is the problem that causes that your examples do not compile, because the n before H is too large and the rest of the format then has no sense.
The next one could be
400 FORMAT(8H 'GAMMA',2X,G13.5,5H 'P0',2X,G13.5,5H 'A1',2X,G13.5)
to print
'GAMMA' 1.0000 'P0' 2.0000 'A1' 3.0000
The effect of the above in Fortran 95 and above is better achieved by
print '(A0,2X,G13.5,A0,2X,G13.5,A0,2X,G13.5)', " 'GAMMA'",1.," 'P0'", 2.0, " 'A1'", 3.0
and maybe you would rather use just:
print '(A0,2X,G13.5,A0,2X,G13.5,A0,2X,G13.5)', "GAMMA",1.,"P0", 2.0, "A1", 3.0
for printing
GAMMA 1.0000 P0 2.0000 A1 3.0000
or even
print *, "GAMMA",1.,"P0", 2.0, "A1", 3.0
Related
I have in a data frame a column with code points corresponding to emoji.
They look something like this:
1F1E8
I am using the remoji library, but as you can see my code points do not have \U in front of them, which is necessary for the methods of this library, as far as I know.
Example:
#This works
message (sub_emoji ("This is silly \U1f626"))
#this does not work
message (sub_emoji ("This is silly 1f626"))
The most I've managed to do is transform the code points to \\U1f626 but it doesn't work either.
Thanks in advance
The solution I was trying was to paste the string "\U" at the beginning of the code points, but being the \ an escape character I couldn't do it. But with some "tricks" it can be done:
I transformed all the code points to the following structure (8 hex digits):
\\U000xxxxx (000 if 5 hex digits in the original code point)
\\U0000xxxx (0000 if 4 hex digits in the original code point)
I have not delved into their implication ("fill" with 0), but the truth is that they work the same way, as far as I've tried:
message(sub_emoji("This is silly \U0001f626"))
This is silly 🤦
and
message(sub_emoji("This is silly \U1f626"))
#This is silly 🤦
I "filled" with 0 because I used the function stri_unescape_unicode() to un-escape the code points \\Uxxxxxxxx and get the desired result \Uxxxxxxxx (one \) to pass it to sub_emoji()
And this function, stri_unescape_unicode(), only gives this result (one \) if the code point has 8 hex digits, I did not study why, I only noticed this by messing around. I also noticed that if the u is lowercase it has another effect.
For example:
#it does not work
stri_unescape_unicode("\\U1F926")
#[1] NA
#Warning message: .....
stri_unescape_unicode("\\U1F926\\U1F3FB")
#[1] NA
#Warning message: .....
#it works
stri_unescape_unicode("\\U0001F926")
#[1] "\U0001f926"
stri_unescape_unicode("\\U0001F926\\U0001F3FB")
# [1] "\U0001f926\U0001f3fb"
A complete example:
em = stri_unescape_unicode("\\U0001f626")
message(sub_emoji(paste("This is silly", em)))
#This is silly 🤦
emc = stri_unescape_unicode("\\U0001F926\\U0001F3FB")
message(sub_emoji(paste("This is silly", emc)))
#This is silly 🤦🏻
Pay attention to this last emoji, it has a different skin and hair color, there is the effect of ZWJ Sequence.
So I'm just wondering why my screen looks like this and how do I fix it. The screen splits down the middle where the color changes from orange to green so it looks for only the first part of that file when I run the code. I don't know why it's doing that or how to fix it.
Some compilers allow for a free format but most that I've used (IBM) require fixed. They have Area A and Area B which ends at column 72. If you need to use long literals you'll have to use continuation. The hyphen must appear in col 7 or you'll get a compiler error. This is straight out of the GNUCobol manual but it's the same for IBM.
IDENTIFICATION DIVISION.
PROGRAM-ID. LONGLIT.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 LONG-LITERAL-VALUE-DEMO PIC X(60) VALUE "This is a long l
- "ong literal that
- " must be continu
- "ed.".
PROCEDURE DIVISION.
DISPLAY LONG-LITERAL-VALUE-DEMO
STOP RUN
.
I have one column (im = 160648) and row (jm = 1). I want to transform that to a matrix with sizes (im = 344) and (jm=467)
my program code is
program matrix
parameter (im=160648, jm=1)
dimension h(im,jm)
integer::h
open (1,file="Hasil.txt", status='old')
open (2,file="HasilNN.txt", status='unknown')
do i=1,jm
read(1,*)(h(i,j)),j=1,jm)
end do
do i=1,im
write(2,33)(h(i,j),j=1,jm)
end do
33 format(1x, 344f10.6)
end program matrix
the error code that appears when read(1,*)(h(i,j)),j=1,jm)
the data type is floating data.
Your read loop is:
do i=1,jm
read(1,*)(h(i,j)),j=1,jm)
end do
Shouldn't do i=1,jm be do i=1,im ?
This would imply there are "im" records (lines) in the formatted text file Hasil.txt, which your question suggests.
read(1,*)(h(i,j)),j=1,jm) implies each record (line of text) has "jm" values, which is 1 value per line. Is this what the file looks like ? (An unknown number of blank lines will be skipped with this read (lu,*) ... statement.)
You appear to be wanting to write this information to another file; HasilNN.txt using 33 format (1x, 344f10.6) which suggests 3441 characters per line, although your write statement will write only 1 value per line (as jm=1). This would be a very long line for a text file and probably difficult to manage outside the program. If you did wish to do this, you could achieve this with an implied do loop, such as:
write(2,33) ((h(i,j),j=1,jm),I=1,im)
A few comments:
using jm = 1 implies each row has only one value, which could be equivalently represented as a 1d vector "dimension h(im)", negating the need for j
File unit numbers 1 and 2 are typically reserved unit numbers for screen/keyboard. You would be better using units 11 and 12.
When devising this code, you need to address the record structure in the 2 files, as a simple vector could be used. You can control the line length with the format. A format of (1x,8f10.6) would create a record of 81 characters, which would be much easier to manage.
Format descriptor f10.6 also limits the range of values you can manage in the files. Values >= 1000 or <= -100 will overflow this format, while values smaller than 1.e-6 will be zero.
As #francescalus has noted, you have declared "h" as integer, but use a real format descriptor. This will produce an "Error : format-data mismatch" and has to be changed to what is expected in the file.
You should consider what you wish to achieve and adjust the code.
It says there's an error operator expected. I know this syntax error is in line 5 but I can't figure it out. I have highlighted that line with ** thx.
action(X : Y,0 : Y):-X>0.
action(X : Y,X : 0):-Y>0.
action(X : Y,4:Y):-X<4.
action(X : Y,X : 3):-Y<3.
**action(X : Y,4 : Z):- X<4, Z is Y−(4−X), Z>=0.**
Path(X):-
path(0 : 0,[0 : 0],X).
Prolog predicate names must begin with a lower case letter. So as #CapelliC points out, Path(X) :0-... is going to be a problem.
But your syntax error on line 5 is because you copy/pasted this code from something online or from an eBook perhaps. In your expression, Y−(4−X) those − symbols are not minuses but something else that look like minuses (perhaps EM dashes). Try retyping line 5 manually, and the problem will go away.
This one is a problem:
Y−(4−X)
And this one is correct:
Y-(4-X)
There is actually a subtle difference in length of the dash you can see if you look closely. The second example is an actual dash or minus (ASCII code hex 2d). The first example of a dash is a special character (a hex dump shows a character code of 59 88 92). This is an issue with copy/pasting code from an eBook or other electronic document, since there are several characters used for visual convenience that aren't the specific one required by the language.
the error is the clause following
Path(X):-
...
should be
path(X):-
...
I am attempting to use fortran to write out a comma-delimited file for import into another commercial package. The issue is that I have an unknown number of data columns. My output needs to look like this:
a_string,a_float,a_different_float,float_array_elem1,float_array_elem2,...,float_array_elemn
which would result in something that might look like this:
L1080,546876.23,4325678.21,300.2,150.125,...,0.125
L1090,563245.1,2356345.21,27.1245,...,0.00983
I have three issues. One, I would prefer the elements to be tightly grouped (variable column width), two, I do not know how to define a variable number of array elements in the format statement, and three, the array elements can span a large range--maybe 12 orders of magnitude. The following code conceptually does what I want, but the variable 'n' and the lack of column-width definition throws an error (of course):
WRITE(50,900) linenames(ii),loc(ii,1:2),recon(ii,1:n)
900 FORMAT(A,',',F,',',F,n(',',F))
(I should note that n is fixed at run-time.) The write statement does what I want it to when I do WRITE(50,*), except that it's width-delimited.
I think this thread almost answered my question, but I got quite confused: SO. Right now I have a shell script with awk fixing the issue, but that solution is...inelegant. I could do some manipulation to make the output a string, and then just write it, but I would rather like to avoid that option if at all possible.
I'm doing this in Fortran 90 but I like to try to keep my code as backwards-compatible as possible.
the format close to what you want is f0.3, this will give no spaces and a fixed number of decimal places. I think if you want to also lop off trailing zeros you'll need to do a good bit of work.
The 'n' in your write statement can be larger than the number of data values, so one (old school) approach is to put a big number there, eg 100000. Modern fortran does have some syntax to specify indefinite repeat, i'm sure someone will offer that up.
----edit
the unlimited repeat is as you might guess an asterisk..and is evideltly "brand new" in f2008
In order to make sure that no space occurs between the entries in your line, you can write them separately in character variables and then print them out using theadjustl() function in fortran:
program csv
implicit none
integer, parameter :: dp = kind(1.0d0)
integer, parameter :: nn = 3
real(dp), parameter :: floatarray(nn) = [ -1.0_dp, -2.0_dp, -3.0_dp ]
integer :: ii
character(30) :: buffer(nn+2), myformat
! Create format string with appropriate number of fields.
write(myformat, "(A,I0,A)") "(A,", nn + 2, "(',',A))"
! You should execute the following lines in a loop for every line you want to output
write(buffer(1), "(F20.2)") 1.0_dp ! a_float
write(buffer(2), "(F20.2)") 2.0_dp ! a_different_float
do ii = 1, nn
write(buffer(2+ii), "(F20.3)") floatarray(ii)
end do
write(*, myformat) "a_string", (trim(adjustl(buffer(ii))), ii = 1, nn + 2)
end program csv
The demonstration above is only for one output line, but you can easily write a loop around the appropriate block to execute it for all your output lines. Also, you can choose different numerical format for the different entries, if you wish.