Internal READ question

[nvaneck]

The following code reads the value of D as 1.

REAL D
CHARACTERSTR*6
STR='1,212'
READ(STR,"(F6.0)") D

Is this the way it's supposed to work?

[dboggs]

Sure, because comma-delimited numbers is a pretty standard data format. Fortran thinks your string contains two numbers: 1 and 212. For input, the comma overrides your format edit descripter.

Are you in one of those funny countries where a comma is a decimal and a period is a comma? I think you can set that custom with some kind of a compiler switch, the D would be read as 1.212 (again overriding your format spec).

I think.

[nvaneck]

No, but a user supplied a CSV file saved from Excel with the 1000 separator in the format.  My program caught the field enclosed in quotes, but my read statement behaved as I stated but the embedded commas caught me by surprise.  The documentation said internal reads needed a format, and it is surprising that it is overuled instead of returning an error.  So I figured that 's waht it was and now squeeze out the commas first, but to me it is counter intuitive and seems contraditory with the documentation.

I see this works the same for formated reads from the console as well. Guess this means any data record field from a data file with comas in it is read incorrectly if you've defined the field as fixed width and read with a format--no way to trap the error.  A little scary if you have a data file someone goofed up in in creating.

[IanH]

I'm a bit disappointed by this feature (documented here) - for the input data correctness checking reasons mentioned by nvaneck.  Can it be turned off?

[andrew_4619]

Yup, you are reading 6 characters when only 5 exists. I would hope for an error not a compiler makes best guess which is what you get.

[Les_Neilson]

@app4619 : Not quite.    STR is declared as character*6 and is therefore padded with a trailing blank.

<deleted the bit I put about Open with DECIMAL. Just saw that the comma is a thousands separator.>

[jimdempseyatthecove]

nvaneck, I guess you will have to write a function that performs the edit you desire. This way you can control what happens with respect to if the input has peculiarities or has errors or other ('****" for field overflow in Excel).

Jim Dempsey

[nvaneck]

Well, JIm, I already have one, and have had for decades--it converts numbers fromone format to another, and I was just using the READ statement in this case since I trusted Excel to put only numbers in the CSV file for non-alphabetic types. I just have to squeeze out the commas for Excel CSV files which come in as quoted numbers (trivial) or call my conversion routine.  My complaint is that when a programmer wants to read fixed format records with fields of specific size, that's what he/she should get. 

This is not a problem confined to Excel CSV data.    If I have a datafile with records with n fixed field lengths of a given width, say,4, and I read it with nF4.0, I want an error when a non-number appears in one of the fields, not someone assuming the format is irelevant.  If this is what the standard says, the standard is wrong.

Sorry about the mis-match between STR and the number; it was inadvertent and not germaine to the illustration.

[andrew_4619]

READ(STR(1:6),"(F6.0)",iostat=istat) D 

I would have thought definately should be an error but it isn't

[Les_Neilson]

Good luck in getting the standard changed :-)
Unfortunately there are some cultures which do not group numbers in bunches of thousands. I have seen one situation (search "Indian number system") where the numbers are grouped in sets of 2 and 3.

<quote>
In the Indian system, the number 25,35,05,439 can be read as,“Twenty-five crore thirty-five lakh five thousand four hundred and thirty-nine” In international system, the same number can be read as two hundred fifty-three million five hundred five thousand four hundred and thirty-nine.
<unquote>

Les

[andrew_4619]

@les, It isn't the standard, if you follow the Link in Ian's post  the stuff relating to comma terminating short input field is in green, indicating non-standard behaviour. So does enforcing standard semantics give a rub time error for this?

[Les_Neilson]

@app4619 : You are correct. Somehow I missed Ian's post with the link. Sorry. Strangely I have always just accepted that comma would terminate the field. I suppose it was because I only ever used comma separated data files.

Les

[Steven_L_Intel1]

No, standards warnings doesn't cover run-time behavior.