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 

Is this a Standard ?

 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> General
View previous topic :: View next topic  
Author Message
DanRRight



Joined: 10 Mar 2008
Posts: 2813
Location: South Pole, Antarctica

PostPosted: Mon Jun 13, 2016 12:51 am    Post subject: Is this a Standard ? Reply with quote

I got a reading error while filling real*4 variables with these numbers which led me to this text line in the data file

Code:
 1.8000E-02  7.0438E+00 -8.4720+220


Notice the number without E or D ? Kind of I did not pay attention before to this but is this standard way of writing real*8 numbers ?
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1885

PostPosted: Mon Jun 13, 2016 6:02 am    Post subject: Reply with quote

The only reason to get an error in reading the data that you showed is that the third item has an exponent that is too large for a REAL*4 variable. The standard specifies (look up the section for Fw.d input) that the start of the exponent field may contain an 'e', 'd', 'E', 'D', '+' or '-' .

You may not like leaving out the E/D, and you can certainly make sure that your input data contains the E/D, but the standard does not require it.

The justification? You have to think in terms of punched card input, where being able to leave out the E/D could reduce your card budget by 10 percent.
Back to top
View user's profile Send private message
DanRRight



Joined: 10 Mar 2008
Posts: 2813
Location: South Pole, Antarctica

PostPosted: Mon Jun 13, 2016 6:05 pm    Post subject: Reply with quote

Thanks Mecej4. This is the case when I can definitely live with it if this is a Standard. This behavior of the code is reasonable when the compiler detects an error and that definitely is very useful warning i should not miss. I ignored these errors in this place before and when the code with time became too large and complex and buggy I now pay for that by loosing a lot of time with any small error. Lost one more Saturday, which became like a doom to me lately, I loose now most of Saturdays on some "errors from the hell" (the ones I never had before or the ones hard to find.... I wrote about this devilry effect before) Sad .
Back to top
View user's profile Send private message
John-Silver



Joined: 30 Jul 2013
Posts: 1520
Location: Aerospace Valley

PostPosted: Tue Jun 14, 2016 5:43 am    Post subject: Reply with quote

it's always a good idea to build in checks on the validity of the numbers to threshold values as they are read in, especially for large sets of input data.
Back to top
View user's profile Send private message
JohnCampbell



Joined: 16 Feb 2006
Posts: 2554
Location: Sydney

PostPosted: Tue Jun 14, 2016 9:17 am    Post subject: Reply with quote

Dan,

According to the Fortran standard, I think the value "-8.4720+22" is a valid number, although I would consider this an error.

John
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1885

PostPosted: Wed Sep 07, 2016 1:10 pm    Post subject: Reply with quote

John, I just noticed that that you wrote "-8.4720+22"; what Dan's data file had, however, was "-8.4720+220". Without the third digit ('0') in the exponent field, the input number would have been well within the range of REAL, and no runtime error would have been issued.
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 -> General All times are GMT + 1 Hour
Page 1 of 1

 
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