forums.silverfrost.com Forum Index forums.silverfrost.com
Welcome to the Silverfrost forums
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Initialization via data statements fails
Goto page 1, 2  Next
 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Support
View previous topic :: View next topic  
Author Message
wahorger



Joined: 13 Oct 2014
Posts: 852
Location: Morrison, CO, USA

PostPosted: Wed Oct 07, 2020 12:09 am    Post subject: Initialization via data statements fails Reply with quote

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
View user's profile Send private message Visit poster's website
wahorger



Joined: 13 Oct 2014
Posts: 852
Location: Morrison, CO, USA

PostPosted: Wed Oct 07, 2020 2:27 am    Post subject: Reply with quote

Compiler Version 8.64.0, same with the DLL's.
Back to top
View user's profile Send private message Visit poster's website
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 6591
Location: Salford, UK

PostPosted: Wed Oct 07, 2020 9:27 am    Post subject: Reply with quote

Thank you for the feedback. I have made a note of this failure.
Back to top
View user's profile Send private message AIM Address
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 6591
Location: Salford, UK

PostPosted: Wed Oct 07, 2020 4:28 pm    Post subject: Reply with quote

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
View user's profile Send private message AIM Address
wahorger



Joined: 13 Oct 2014
Posts: 852
Location: Morrison, CO, USA

PostPosted: Wed Oct 07, 2020 6:29 pm    Post subject: Reply with quote

The Plato Project FORUMTESTING contains the relevant files.

That said, I shall pare it down.

Done.

Bill
Back to top
View user's profile Send private message Visit poster's website
wahorger



Joined: 13 Oct 2014
Posts: 852
Location: Morrison, CO, USA

PostPosted: Wed Oct 14, 2020 12:15 am    Post subject: Reply with quote

The ZIP file has been updated at the link below.

https://www.dropbox.com/s/wt4i5nky5x1e878/FPStackFault.zip?dl=0

Apparently once one establishes a link in DropBox, the file is "frozen". Apologies for not realizing this.
Back to top
View user's profile Send private message Visit poster's website
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 6591
Location: Salford, UK

PostPosted: Thu Oct 15, 2020 8:21 am    Post subject: Reply with quote

Thanks.
Back to top
View user's profile Send private message AIM Address
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 6591
Location: Salford, UK

PostPosted: Sat Oct 17, 2020 3:36 pm    Post subject: Reply with quote

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
View user's profile Send private message AIM Address
wahorger



Joined: 13 Oct 2014
Posts: 852
Location: Morrison, CO, USA

PostPosted: Sun Oct 18, 2020 6:46 pm    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 6591
Location: Salford, UK

PostPosted: Mon Oct 19, 2020 6:55 am    Post subject: Reply with quote

Bill

It might be easier to remove trailing zeros from the data where these are redundant.
Back to top
View user's profile Send private message AIM Address
LitusSaxonicum



Joined: 23 Aug 2005
Posts: 2187
Location: Yateley, Hants, UK

PostPosted: Mon Oct 19, 2020 9:40 am    Post subject: Reply with quote

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
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 6591
Location: Salford, UK

PostPosted: Mon Oct 19, 2020 11:49 am    Post subject: Reply with quote

Yes, and there are approximately 15 significant figures with double precision. So one would hope that truncation is always admissible.
Back to top
View user's profile Send private message AIM Address
mecej4



Joined: 31 Oct 2006
Posts: 1429

PostPosted: Mon Oct 19, 2020 12:05 pm    Post subject: Reply with quote

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
View user's profile Send private message
JohnCampbell



Joined: 16 Feb 2006
Posts: 2239
Location: Sydney

PostPosted: Mon Oct 19, 2020 12:49 pm    Post subject: Reply with quote

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
View user's profile Send private message
LitusSaxonicum



Joined: 23 Aug 2005
Posts: 2187
Location: Yateley, Hants, UK

PostPosted: Mon Oct 19, 2020 1:16 pm    Post subject: Reply with quote

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
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Support All times are GMT + 1 Hour
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
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