Silverfrost Forums

Welcome to our forums

Is this a Standard ?

12 Jun 2016 11:51 #17640

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

 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 ?

13 Jun 2016 5:02 #17641

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.

13 Jun 2016 5:05 #17656

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) 😦 .

14 Jun 2016 8:17 #17659

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

7 Sep 2016 12:10 #17993

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.

Please login to reply.