Re: non-robust way of reading a "csv" file
- From: Dave Allured <nospom@xxxxxxxxxx>
- Date: Mon, 16 Feb 2009 09:24:09 -0700
e p chandler wrote:
On Feb 15, 2:32 am, Dave Allured <nos...@xxxxxxxxxx> wrote:
e p chandler wrote:
While reading MR&C about the action of the / edit descriptor and list
directed input, I decided to try this method of reading a CSV file
with a variable number of items in each record. This method is not
particularly robust but it does work - within its limitations.
In section 9.9 - List-directed I/O - p. 192
".. a _null_value_ and the corresponding item in the input list is
left unchanged... When a slash separater is encountered, null values
are given to any remaining list itmes."
--- start text ---
implicit none
character*80 s
character*81 t
integer ierr
real r(10)
open(10,file='z.csv')
do
r=-999
read(10,'(a)',iostat=ierr) s
if (ierr /= 0) exit
t = s // '/'
read(t,*) r
print *,r
end do
print *,'ierr=',ierr
end
--- end text ---
--- input file ---
1
1,2
1,2,3
1,2,3,4,5,6
1,2,3,4,5,6,7,8,9,10
1,2,3,4,5,6,7,8,9,10,11
3,2,1,0
--- end file ---
--- output ---
-999. -999. -999. -999. -999. -999. -999. -999. -999. -999.
1. -999. -999. -999. -999. -999. -999. -999. -999. -999.
1. 2. -999. -999. -999. -999. -999. -999. -999. -999.
1. 2. 3. -999. -999. -999. -999. -999. -999. -999.
1. 2. 3. 4. 5. 6. -999. -999. -999. -999.
1. 2. 3. 4. 5. 6. 7. 8. 9. 10.
1. 2. 3. 4. 5. 6. 7. 8. 9. 10.
3. 2. 1. 0. -999. -999. -999. -999. -999. -999.
ierr= -1
--- end text ---
Of coures this leaves the user with the "missing-value" problem!
Well that seems to me like a rather nice and simple way of reading CSV.
But I am left wondering:
1. I do not have a copy of that reference. What exactly do they mean
by "null values are given" ?? From above, it is not at all clear to me
that "null values" are equivalent to leaving unchanged the original,
pre-read contents of list items.
2. Which versions of Fortran standards, if any, specify this behavior
of the slash separator with list directed input?
3. How common among compilers is implementation of the slash separator
like this?
4. Why do you say "not particularly robust" ?
There are a number of problems with what I just did. There are all
sorts of ways for my program to fail. For example on input data
records more than 80 characters long. Supposing one of the data items
is a string instead of a number. You have to know in advance what type
your data is and adjust your I/O list accordingly. Characters such as
* or / have other meanings in list-directed I/O but not in CSV, etc.
[flame on]
Blame Microsoft or Software Arts or Lotus. It really goes back to
READ / WRITE in BASIC as opposed to INPUT / PRINT. Just another form
of "YML". (Yucky markup language).
[flame off]
Thanks for the explanation. For common situations with only numeric
data, where things like the maximum line length and number of items per
line are well understood, this is a good method for reading variable
width arrays. For more complicated data, I have written CSV parsing
subroutines that are application specific.
--Dave
.
- References:
- non-robust way of reading a "csv" file
- From: e p chandler
- Re: non-robust way of reading a "csv" file
- From: Dave Allured
- Re: non-robust way of reading a "csv" file
- From: e p chandler
- non-robust way of reading a "csv" file
- Prev by Date: Re: Are these the same arguments?
- Next by Date: Re: non-robust way of reading a "csv" file
- Previous by thread: Re: non-robust way of reading a "csv" file
- Next by thread: Re: non-robust way of reading a "csv" file
- Index(es):
Relevant Pages
|
Loading