View previous topic :: View next topic |
Author |
Message |
wahorger
Joined: 13 Oct 2014 Posts: 1217 Location: Morrison, CO, USA
|
Posted: Wed Oct 07, 2020 12:09 am Post subject: Initialization via data statements fails |
|
|
I have attached a link to my Project on DropBox (too long to post). Simple enough. It initializes several arrays that are in named common via DATA statements.
The issue is in the first rows at Line 167 in the INCLUDE file.
Code: | $ "AL E","T", 101, 85.833333333333D0, 200000.000000000000D0,30.500000000000D0, 25000.000000000000D0,0.000000000000D0,0.000000000000D0,
|
The variable SPCC_83 (1,1:6) is not initialized properly. The print statement shows that the second element will be set to 215.25.
Quote: |
85.8333333333 215.250000000 200000.000000 13.5000000000
1.00000000000 100000.000000
|
Every other element is, as far as I can determine, proper.
I would appear that this 215.25 is inserted, since the elements that follow are correct, just displaced by one array position.
https://www.dropbox.com/s/wim9oemo7thzyhy/FPStackFault.zip?dl=0 |
|
Back to top |
|
|
wahorger
Joined: 13 Oct 2014 Posts: 1217 Location: Morrison, CO, USA
|
Posted: Wed Oct 07, 2020 2:27 am Post subject: |
|
|
Compiler Version 8.64.0, same with the DLL's. |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7916 Location: Salford, UK
|
Posted: Wed Oct 07, 2020 9:27 am Post subject: |
|
|
Thank you for the feedback. I have made a note of this failure. |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7916 Location: Salford, UK
|
Posted: Wed Oct 07, 2020 4:28 pm Post subject: |
|
|
Bill
There are a lot of files in your archive. Is it possible for you to represent the fault in a small program? |
|
Back to top |
|
|
wahorger
Joined: 13 Oct 2014 Posts: 1217 Location: Morrison, CO, USA
|
Posted: Wed Oct 07, 2020 6:29 pm Post subject: |
|
|
The Plato Project FORUMTESTING contains the relevant files.
That said, I shall pare it down.
Done.
Bill |
|
Back to top |
|
|
wahorger
Joined: 13 Oct 2014 Posts: 1217 Location: Morrison, CO, USA
|
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7916 Location: Salford, UK
|
Posted: Thu Oct 15, 2020 8:21 am Post subject: |
|
|
Thanks. |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7916 Location: Salford, UK
|
Posted: Sat Oct 17, 2020 3:36 pm Post subject: |
|
|
Bill
FTN95 has a maximum line length of 32K characters and this limit must have been exceeded in this data statement.
As a rough calculation you have 212x135 + 104 characters which is less than 32K but getting close.
I suggest that you reduce the number of decimal places in the data where this is possible.
I will take a look to see why this has not been faulted.
At first sight, it looks like the extra characters have wrapped around in some way, either in the line buffer or because the DATA statement has not found enough data. |
|
Back to top |
|
|
wahorger
Joined: 13 Oct 2014 Posts: 1217 Location: Morrison, CO, USA
|
Posted: Sun Oct 18, 2020 6:46 pm Post subject: |
|
|
Paul, thanks. I'll take a look and see if breaking up the DATA into smaller chucks can correct the issue. I'll also look through other DATA sections to see if I did this somewhere else!!
Bill |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7916 Location: Salford, UK
|
Posted: Mon Oct 19, 2020 6:55 am Post subject: |
|
|
Bill
It might be easier to remove trailing zeros from the data where these are redundant. |
|
Back to top |
|
|
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2388 Location: Yateley, Hants, UK
|
Posted: Mon Oct 19, 2020 9:40 am Post subject: |
|
|
Paul,
I suppose that you mean that 0.0D0 is exactly the same as 0.00000000D0.
I wonder if there have ever been compilers where this is not so?
Eddie |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7916 Location: Salford, UK
|
Posted: Mon Oct 19, 2020 11:49 am Post subject: |
|
|
Yes, and there are approximately 15 significant figures with double precision. So one would hope that truncation is always admissible. |
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1885
|
Posted: Mon Oct 19, 2020 12:05 pm Post subject: |
|
|
Eddie, real/double zero is a special case; so are integers that can be represented in 24 bits or less. Conversion of reals with these values to integers or to reals of a different precision results in no loss of accuracy.
A more realistic example is shown in the following program:
Code: | program tst
implicit none
real :: r1 = 0.1234
double precision :: d1 = 0.1234d0, result
!
result=r1
print *,result
result=d1
print *,result
end program |
The output:
Code: | 0.123400002718
0.123400000000 |
shows that the single precision constant 0.1234 may not be suitable as a value for setting into a double precision variable, if the trailing digits 2718 are unacceptable as replacements for 0000.
-------
In Bill's program, I do not know why he needs to use DATA to assign values to hundreds or thousands of variables. Putting that many constants into a source file, with lines extended beyond 132 columns, is almost asking for trouble.
Why not put the values into a text file, and read that file once at the beginning? If speed is a concern, convert that text file to an unformatted binary file once, and read that unformatted file at the beginning of a run.
Last edited by mecej4 on Mon Oct 19, 2020 2:44 pm; edited 1 time in total |
|
Back to top |
|
|
JohnCampbell
Joined: 16 Feb 2006 Posts: 2554 Location: Sydney
|
Posted: Mon Oct 19, 2020 12:49 pm Post subject: |
|
|
Also, the advantage of a text file is that text reals are interpreted at the same precision as the variable,
so in a text file 0.10000000D0 is the same as 0.1 (which is the same as 0.1D0), while "d = 0.1" is the classic example of precision fail.
Try Code: | real*8 :: d = 0.1
character text*8
write (*,*) 'real*8 :: d = 0.1', d
d = 0.1
write (*,*) 'd = 0.1 ', d
text = ' 0.1 '
read (text,*) d
write (*,*) 'read (text,*)', d
d = 0.1d0
write (*,*) 'd = 0.1d0 ', d
end |
The data statement approach is different in F77.
I often use minimal text for real*8 constants, as the following all give the same value to "d"
Code: | real*8 d
d = 3.0d0
d = 3.
d = 3 |
|
|
Back to top |
|
|
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2388 Location: Yateley, Hants, UK
|
Posted: Mon Oct 19, 2020 1:16 pm Post subject: |
|
|
Mecej4,
I would expect zero to be zero, as it is perfectly representable in all Fortran numeric formats. See here, in old-fashioned Fortran:
Code: | PROGRAM TST
REAL*8 A, B
DATA A, B / 0.0D0, 0.00000000000D0 /
WRITE(*,100) A, B, A-B, A+B
100 FORMAT(4D20.10)
END |
I think that I would expect many small integers to be represented exactly in single or double precision as defined in DATA or an assignment, and especially even numbers or powers of two. I just wouldn't rely on it. I wouldn't expect any general floating point number to be held exactly.
Putting all your defined values in a single DATA statement does seem to me to be making a rod for your own back, as the chance of understanding it later is really rather slim.
Eddie |
|
Back to top |
|
|
|