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 

Saturday devilry

 
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: 2532
Location: South Pole, Antarctica

PostPosted: Sat Apr 09, 2022 6:52 pm    Post subject: Saturday devilry Reply with quote

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



Joined: 31 Oct 2006
Posts: 1693

PostPosted: Sun Apr 10, 2022 3:58 am    Post subject: Reply with quote

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:

Code:
     4.000000E+19
Back to top
View user's profile Send private message
DanRRight



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

PostPosted: Sun Apr 10, 2022 6:31 am    Post subject: Reply with quote

Mecej4,
Here is the screenshot of source in SDBG64 and data file
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Sun Apr 10, 2022 8:55 am    Post subject: Reply with quote

Dan

We need a short working program together with the content of the input file.
Back to top
View user's profile Send private message AIM Address
mecej4



Joined: 31 Oct 2006
Posts: 1693

PostPosted: Sun Apr 10, 2022 10:53 am    Post subject: Fw.d Gotcha Reply with quote

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



Joined: 16 Feb 2006
Posts: 2387
Location: Sydney

PostPosted: Mon Apr 11, 2022 9:29 am    Post subject: Reply with quote

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



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

PostPosted: Mon Apr 11, 2022 9:37 am    Post subject: Reply with quote

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


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

PostPosted: Mon Apr 11, 2022 12:36 pm    Post subject: Reply with quote

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



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

PostPosted: Mon Apr 11, 2022 10:12 pm    Post subject: Reply with quote

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



Joined: 16 Feb 2006
Posts: 2387
Location: Sydney

PostPosted: Tue Apr 12, 2022 4:23 am    Post subject: Reply with quote

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



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

PostPosted: Tue Apr 12, 2022 8:14 am    Post subject: Reply with quote

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



Joined: 31 Oct 2006
Posts: 1693

PostPosted: Tue Apr 12, 2022 10:58 am    Post subject: Reply with quote

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



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

PostPosted: Tue Apr 12, 2022 9:54 pm    Post subject: Reply with quote

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
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