forums.silverfrost.com

DanRRight · Posted: Fri Oct 20, 2023 11:27 am Post subject: Spaces as zeroes

How to avoid treating spaces as zeroes when reading integer number like read(11,*) ? I forgot about such unusual behavior of Fortran and got caught Sad

wahorger · Joined: 13 Oct 2014 Posts: 1217 Location: Morrison, CO, USA

Reading numbers with the implied format ("*") has no effect from spaces.

Here's the output from the program below. I input a "1" with trailing spaces, the "2" with leading space, and the "3 4 5 6" just to have it only read the first one.

Kenneth_Smith · Posted: Fri Oct 20, 2023 7:06 pm Post subject:

The B, BN, and BZ specifiers control interpretation of embedded and trailing blanks for numeric input, but you should not have to use these for read(11,*).

DanRRight · Posted: Sat Oct 21, 2023 3:14 am Post subject:

Thanks for suggestions!

I used internal read like this ( i expected to read floating point number but it was by mistake integer)

wahorger · Joined: 13 Oct 2014 Posts: 1217 Location: Morrison, CO, USA

Dan, I am still confused by your examples given.

If one uses the "*" format specifier, the results of reading into an integer or a real is the same. "1" is interpreted properly because the "*" stops scanning the string at the first non-numeric character. As far as the READ is concerned, there is no difference between the "1" as an integer or a real. It is the data type in the READ itself that determines how the data are to be scanned/stored.

When reading using an explicit format like "(i10)", the rule used is different. In that case, the entire 10 characters is used, with spaces becoming zeroes. This is per the standard. If you wish it to be interpreted in a different way, then you have to use Ken's suggestion. And I agree with Ken, a "*" does what you wish it to so far as your simple example goes.

One thing I've done is to use the ERR= or IOSTAT= to check the data type of an input. I extract a portion I wish to "analyze" into a string, then subject it to the appropriate READ (using the "*" format specifier) per the appropriate type and including the ERR= and/or IOSTAT=. If it fails, then there is an issue with the data. If it succeeds, then we're OK, I store the result and move to the next item. This is used almost exclusively with user created inputs.

Using your example, if you specified a decimal point after the "1", then the integer read fails, while the real read succeeds.

DanRRight · Posted: Sat Oct 21, 2023 5:03 pm Post subject:

Needless to say i am confused even more. So for a while i check for the point in the number, and if it exists, i read it as real number, if absent - as integer. When i will have more time we will return to this example, i have several places in my codes similarly crazy, and some exist for months but i do not have any time to dig for the reason, it is easy just to find the workarounds which somehow work. This is not just me who got such present from the devilry. Our people got some experimental numbers which are 15x larger than commonly reported before and now i am getting the simulations which do not confirm any of sides Smile