View previous topic :: View next topic |
Author |
Message |
DanRRight
Joined: 10 Mar 2008 Posts: 2826 Location: South Pole, Antarctica
|
Posted: Sat Apr 09, 2022 6:52 pm Post subject: 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 |
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1892
|
Posted: Sun Apr 10, 2022 3:58 am Post subject: |
|
|
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.
Code: | character(4) :: str = '4e19'
read (str,*)x
print *,x
end
|
The output from it:
|
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2826 Location: South Pole, Antarctica
|
Posted: Sun Apr 10, 2022 6:31 am Post subject: |
|
|
Mecej4,
Here is the screenshot of source in SDBG64 and data file |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7933 Location: Salford, UK
|
Posted: Sun Apr 10, 2022 8:55 am Post subject: |
|
|
Dan
We need a short working program together with the content of the input file. |
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1892
|
Posted: Sun Apr 10, 2022 10:53 am Post subject: Fw.d Gotcha |
|
|
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 http://forums.silverfrost.com/viewtopic.php?t=4624 . 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. |
|
Back to top |
|
|
JohnCampbell
Joined: 16 Feb 2006 Posts: 2559 Location: Sydney
|
Posted: Mon Apr 11, 2022 9:29 am Post subject: |
|
|
A more extensive example.
I always use fmt='(f10.0)' to overcome this problem, and try to include a . in real values.
Code: | 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
Code: |
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)
|
|
|
Back to top |
|
|
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2390 Location: Yateley, Hants, UK
|
Posted: Mon Apr 11, 2022 9:37 am Post subject: |
|
|
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 |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7933 Location: Salford, UK
|
Posted: Mon Apr 11, 2022 12:36 pm Post subject: |
|
|
I have checked this and FTN95 gives the same result as two other compilers.
For an explanation see mecej4's post above. |
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2826 Location: South Pole, Antarctica
|
Posted: Mon Apr 11, 2022 10:12 pm Post subject: |
|
|
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 |
|
Back to top |
|
|
JohnCampbell
Joined: 16 Feb 2006 Posts: 2559 Location: Sydney
|
Posted: Tue Apr 12, 2022 4:23 am Post subject: |
|
|
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 !! |
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2826 Location: South Pole, Antarctica
|
Posted: Tue Apr 12, 2022 8:14 am Post subject: |
|
|
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. |
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1892
|
Posted: Tue Apr 12, 2022 10:58 am Post subject: |
|
|
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. |
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2826 Location: South Pole, Antarctica
|
Posted: Tue Apr 12, 2022 9:54 pm Post subject: |
|
|
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. |
|
Back to top |
|
|
|