Saturday devilry

You all know Saturdays always shock me. Why if you read the number 4e19 without the dot (unlike we usually do: 4.e19) it will be read as 4e17, essentially any such numbers will be two orders of magnitude smaller ?

I got the habit lately to omit the dot and was bitten up for that

Dan: 'Why if you read the number 4e19 without the dot (unlike we usually do: 4.e19) it will be read as 4e17?'

Dan, more details, please. The following program does what is expected.

character(4) :: str = '4e19'
read (str,*)x
print *,x
end

The output from it:

     4.000000E+19

Mecej4, Here is the screenshot of source in SDBG64 and data file

Dan

We need a short working program together with the content of the input file.

As far as formatted input is concerned, Ew.d is interpreted exactly as Fw.d. Below, I have underlined the part of the rule that pertains to your case, with the decimal symbol omitted.

The Fortran standard says, 'The form of the mantissa is an optional sign, followed by a string of one or more digits optionally containing a decimal symbol, including any blanks interpreted as zeros. The d has no effect on input if the input field contains a decimal symbol. If the decimal symbol is omitted, the rightmost d digits of the string, with leading zeros assumed if necessary, are interpreted as the fractional part of the value represented.'

Application of the underlined sentence causes the mantissa portion of the input string, i.e., '4', to be interpreted as '.04' since 'd' in 'E10.2' is '2', and the decimal point was not provided. A leading zero was added since the string had fewer characters (= 1) than d (= 2).

More traps wait for you. The input string for KEYANIN is '0 '. Suppose that the value was '5 ' instead of '0 '. Depending on whether the corresponding format string contained a prior 'BZ', or if the input file was opened with BLANK = 'ZERO', the value of the variable would be 50 rather than the present value of 5.

For data safety, right justify integer input fields and include the decimal point in real input fields.

I created a reproducer for this issue, but ran into another bug related to opening the input file with BLANK='ZERO', which I reported at https://forums.silverfrost.com/Forum/Topic/4139 . You can, however, remove BLANK='ZERO' from the reproducer and what is left should serve to show the effect of reading into a REAL/DOUBLE variable from an input string that does not contain a decimal point.

A more extensive example. I always use fmt='(f10.0)' to overcome this problem, and try to include a . in real values.

character(10) :: str
real :: x
integer :: i
str = '4e19'
do i = 1,2
  write (*,'(a)') ' ', str
  read (str,*)x
  print *,x, ' *'
  read (str,fmt='(e10.2)')x
  print *,x, '(e10.2)'
  read (str,fmt='(f10.0)')x
  print *,x, '(f10.0)'
  read (str,fmt='(f10.2)')x
  print *,x, '(f10.2)'
  str = '4.e19'
end do
end

This gives

4e19      
     4.000000E+19 *
     4.000000E+17(e10.2)
     4.000000E+19(f10.0)
     4.000000E+17(f10.2)

4.e19     
     4.000000E+19 *
     4.000000E+19(e10.2)
     4.000000E+19(f10.0)
     4.000000E+19(f10.2)

Just out of interest, what is the parameter that has a value of 40,0000,000,000,000,000,000?

Number of rupees in Mrs Sunak's bank account?

Eddie

I have checked this and FTN95 gives the same result as two other compilers.

For an explanation see mecej4's post above.

Thanks all Paul, but it should not be like this, isn't it? The number 4e19 must be read as 4e19 or 4.e19 (with all John's demo cases above). Or popup error/warning must be displayed. It was a miracle i noticed this defect in terabytes of my data. Glad i was using numbers without the dot for the first time in my regular files. In the Clearwin feed i use them permanently recently and it is clever enough to resolve this. Basically it was the Clearwin/Excell/Browsers/Cellphones which developed this habit 😃

Dan,

This response to E10.2 or F10.2 was utilised in 60's and 70's with fixed format data reading for minimum characters used on punched cards. It is a legacy case, which my software still includes !!

Use BN,E10.0 or BN,F10.0 to get what you want, or easier still include a '.' with real numbers. I learnt this 50 years ago !!

I add the point to 4.e19 and the E10.2 format will be ignored as if it does not exist. Will it be e10.2 or e10.5 does not matter.

Now I do not add the point to 4e19 which is the same as 4.e19 and by some absurd reason i will lose 2 orders of magnitude...Never seen more bizarre thing.

As John already stated, you should be using Fw.0 as your format descriptor if you want to read input strings that may not contain a decimal point.

You chose E10.2, which is an unwise choice for two reasons:

(a) you or people who run your program may forget that Ew.d is the same as Fw.d for input, and expect that Ew.d will give you behaviour different from Fw.d,

(b) you do not accept how the value of the d in Fw.d affects the way in which the processor scales the input mantissa when no decimal point is present in the input string.

I don't think that a compiler vendor is going to implement non-standard treatment of formatted I/O just because one user demands such behaviour.

Yea, the last in the world anyone would expect that the exponent will be affected by the presence or absence of the dot !!! With F format i know this happens but with E one i am really really shocked.

This is not one user problem, this is more an error prone counterintuitive gray confusion area for most of typical Fortran users who might find Fortran full of such pitfalls and will avoid it.