comma delimited file 
Author Message
 comma delimited file

How one can read in fortran free formatted(ascii) file
where there are commas in between the (numeric)fields?
Thank you MH.



Wed, 18 Jun 1902 08:00:00 GMT  
 comma delimited file

Quote:

>How one can read in fortran free formatted(ascii) file
>where there are commas in between the (numeric)fields?
>Thank you MH.

       read(iun, *) a, b, c, d           etc.

                     or

       real*4 rval(10)
       read(iun, *) rval

       Either of these will work as long as there is a decimal point in each
field of the input file.  The values in the input file may be separated by
commas, spaces, or tabs.

--
James Patterson, Sr. Programmer/Analyst
Sverdrup Technology, Inc.
Arnold AF Base, TN



Wed, 18 Jun 1902 08:00:00 GMT  
 comma delimited file

Say that your data is in a file with 6 numeric data elements per line,
such as:

1.0, 3, 10.5, 6, 11.3, 8
2.0, 4, 12.6, 7, 13.7, 112
etc.

Then you can read the data as follows:

      PROGRAM RDATA
      IMPLICIT NONE

      INTEGER IUNIT
      INTEGER IOERR
      INTEGER I

      REAL A(6)

      IUNIT = 20

     OPEN (IUNIT, FILE='filename',IOSTAT=IOERR)
     IF ( IOERR .NE. 0 ) THEN
         WRITE (*,*) 'Input file not opened'
          STOP
      ENDIF

   10 READ (IUNIT,*,END=999) (A(I),I=1,6)

*   Do what you need to do with the data:

     GOTO 10

  999 WRITE (*,*) 'End of data file'

*  Do what you need when all of the data has been read in:

      STOP
      END

  --

Custom Solutions              http://www.cs-software.com/
7638 Oldridge Road
Charleston, SC  29418          Your source for discounted
Voice:  (803) 760 0597           Fortran compilers and
Fax:    (803) 552 3239             related software

Quote:

> How one can read in fortran free formatted(ascii) file
> where there are commas in between the (numeric)fields?
> Thank you MH.



Wed, 18 Jun 1902 08:00:00 GMT  
 comma delimited file

Quote:


>>How one can read in fortran free formatted(ascii) file
>>where there are commas in between the (numeric)fields?
>>Thank you MH.

>       read(iun, *) a, b, c, d           etc.

>                     or

>       real*4 rval(10)
>       read(iun, *) rval

>       Either of these will work as long as there is a decimal point in each
>field of the input file.  The values in the input file may be separated by
>commas, spaces, or tabs.

Some small notes:

1. The decimal point is not needed, e.g. 10 or 10.0 will give the same value
for a real item.
2. A decimal point is not allowed in an integer item.
3. End of record will also be treated as a separator if the list contains
more items, thus more than one record can be read with one read statement.
4. The use of tabs is not covered by the standard, thus system dependent.
But most (all?) systems convert them to blank(s).

Greetings,
Kurt


Department of Building Science, Lund Institute of Technology
Lund University, Sweden



Wed, 18 Jun 1902 08:00:00 GMT  
 comma delimited file

 [about list-directed input]

Quote:
> 4. The use of tabs is not covered by the standard, thus system dependent.
> But most (all?) systems convert them to blank(s).

I don't have data to know whether or not the "most" is accurate.
"All" certainly isn't.  (Just last week, I showed a user the
unix expand command and the emacs untabify command as easy ways to
handle a tab-delimitted file that they were having trouble reading.
It seemed easier than explicitly parsing for the application at hand).

--
Richard Maine



Wed, 18 Jun 1902 08:00:00 GMT  
 comma delimited file


Quote:

> > 4. The use of tabs is not covered by the standard, thus system dependent.
> > But most (all?) systems convert them to blank(s).

> I don't have data to know whether or not the "most" is accurate.
> "All" certainly isn't.  

However the system treats them, tabs in source code are DEFINITELY
NONSTANDARD.  If it is `not covered by the standard' it is nonstandard.
Tabs are not part of the Fortran character set.  I was a bit
disappointed, after PURCHASING the Numerical Recipes code, to find that
they contain tabs, although they claim to be standard conforming.  I've
complained about this, but never got an answer. (Email response was
quick when I was asking how to pay:)

I read once somewhere (probably in the UNIX HATER'S HANDBOOK) that it
was just an oversight to have tabs in make files, but this was not
changed due to backwards compatibility.  At the time, make had about 5
users.

--

Nuffield Radio Astronomy Laboratories   Tel. ..... +44 1477 571 321 (ext. 297)
Jodrell Bank                            Fax ................. +44 1477 571 618
Macclesfield                            Telex ................. 36149 JODREL G
UK-Cheshire SK11 9DL                    Web .... http://www.jb.man.ac.uk/~pjh/

My opinions are not necessarily those of NRAL or the University of Manchester.



Wed, 18 Jun 1902 08:00:00 GMT  
 comma delimited file

Quote:

> However the system treats them, tabs in source code are DEFINITELY
> NONSTANDARD.  If it is `not covered by the standard' it is nonstandard.
> Tabs are not part of the Fortran character set.  I was a bit
> disappointed, after PURCHASING the Numerical Recipes code, to find that
> they contain tabs, although they claim to be standard conforming.  I've
> complained about this, but never got an answer. (Email response was
> quick when I was asking how to pay:)

It really isn't an issue of standards conformance how source files
are processed for use as Fortran programs.  It is a quality-of-
implementation issue for an implementation (compiler); if it
doesn't process tabs in a canonical way, that means it won't
easily compile code that uses tabs.  But writing a tool
that replaces tabs with the appropriate number of spaces shouldn't
be too much of a hassle.

Ideally, though, vendors of Fortran source code will attempt to use
a format that is transformed to standard-conforming Fortran by all,
or at least most, of the Fortran compilers still in use.  That means
using only spaces, only upper case (probably the first thing to "go"
if they want to relax a bit), not using backslashes, etc.

If you want to write code in a source-file format that is as "close"
to what the FORTRAN 77 standard mandates as possible, you have to use
all upper case, no backslashes, no pound signs, etc., and make
each and every line exactly 72 characters long, including trailing
spaces where necessary!

And, even then, whatever your operating system uses to break
lines (newline character, record delimiters, etc.) ensures that
the source file is not, in fact, standard-conforming.

That's because the standard leaves the method by which an
implementation transforms source files for use as Fortran
programs up to that implementation.

Therefore, there *is* no such thing as a source file on any
computer system that is a FORTRAN-77-standard-conforming file,
since each Fortran implementation (compiler) gets to decide
how to transform a computer systems' file into Fortran source
lines and such.

I don't think this has changed for F90 or F95, offhand.  Though,
I think it's safe to say F90's free form is much easier to
write "agreeable" source files for, in that most any implementation
will accept it (that is, its method of transformation will likely
result in a program that is not blatanly non-standard-conforming).

In the fixed-form, F77 world, most compilers' methods of
transformations include automatically breaking up visually
distinct lines, e.g. newlines, into distinct Fortran source
lines; padding short lines with spaces (though, e.g., Digital
Fortran does not do this by default, IIRC); perhaps a bit
less widely done, converting lower-case to upper-case except
in character/hollerith constants; and converting initial tabs
to either 5 or 6 spaces, depending on whether the immediately
following character is a digit (5) or not (6).  But some
convert other tabs to the tab character, which can find its
way into character/hollerith constants as such; some convert
*all* tabs into the number of spaces needed to get to the
next modulo-8 tab stop, and recognize the resulting line
beginning with a digit in, effectively, column 9 as a
non-standard continuation line; and so on.  The differences
are important when it comes to getting near the column-72
boundary and forming character/hollerith constants.  Even how
compilers handle carriage-return, aka \r, aka ^M, differs; I
think f2c puts it into character/hollerith constants as such,
while IIRC g77 just ignores it entirely.

The free-form world has fewer of these "warts", in that it
doesn't have as many sensitivities to column placement, leading
blanks/spaces, etc.

However, even in the free-form world, precisely how a compiler
chooses to transform tabs, carriage returns, backslashes, and
so on, can affect the degree to which source files using these
characters are portable.  For example, in free form, a processor
probably could safely replace tabs with *single* spaces in its
transformation process, instead of up to eight; choose to replace
carriage returns with a single space instead of ignoring them;
choose to replace `\\' with a single backslash instead of two;
and so on.

The result is that source files with lines coming near the
132-column boundary limit in free-form source can be sensitive
to such differences.

And, yet, nothing I've described above inherently makes either
the source files, or the implementations, non-standard-conforming!

Quote:
> I read once somewhere (probably in the UNIX HATER'S HANDBOOK) that it
> was just an oversight to have tabs in make files, but this was not
> changed due to backwards compatibility.  At the time, make had about 5
> users.

And, as I like to point out, that decision alone has cost "bazillions"
of lost programmer hours due to bugs and such.  The more I learn
about proper language design (mostly, what *not* to do, even if
it seems "cool", "elegant", "powerful", etc.), the more insight I
feel I get into just how much time is wasted dealing with tools
and languages that ensconse mistakes like this.  (In this case,
relying on the distinction between tabs and spaces, or on the
presence or absence of trailing whitespace, and on column
placement beyond column-1-or-not in general, is unwise in any
language that will be used in a computing environment where displays
and printers normally show no visible distinction between tabs and
spaces, or their absence, as when they are at the ends of lines.)
--

"Practice random senselessness and act kind of beautiful."



Wed, 18 Jun 1902 08:00:00 GMT  
 comma delimited file


Quote:


> > However the system treats them, tabs in source code are DEFINITELY
> > NONSTANDARD.  If it is `not covered by the standard' it is nonstandard.
> > Tabs are not part of the Fortran character set.  
> It really isn't an issue of standards conformance how source files
> are processed for use as Fortran programs.  It is a quality-of-
> implementation issue for an implementation (compiler); if it
> doesn't process tabs in a canonical way, that means it won't
> easily compile code that uses tabs.  But writing a tool
> that replaces tabs with the appropriate number of spaces shouldn't
> be too much of a hassle.

Yes, I did write the tool.  But suppose instead of tabs the file had
contained some other character which is not part of the Fortran
character set, maybe one with the high bit set (i.e. 8-bit ASCII).  If
THAT is standard-conforming, then anything is, and I can't see the
difference between that and tab.  Just because tabs are commonly assumed
to be equivalent to spaces doesn't give them any special (official)
status with respect to Fortran.

Quote:
> Ideally, though, vendors of Fortran source code will attempt to use
> a format that is transformed to standard-conforming Fortran by all,
> or at least most, of the Fortran compilers still in use.  That means
> using only spaces, only upper case (probably the first thing to "go"
> if they want to relax a bit), not using backslashes, etc.

Of course.

Quote:
> If you want to write code in a source-file format that is as "close"
> to what the FORTRAN 77 standard mandates as possible, you have to use
> all upper case, no backslashes, no pound signs, etc., and make
> each and every line exactly 72 characters long, including trailing
> spaces where necessary!

Indeed.

Quote:
> And, even then, whatever your operating system uses to break
> lines (newline character, record delimiters, etc.) ensures that
> the source file is not, in fact, standard-conforming.

Is this really in the same category?  The standard talks about lines and
so on, but surely their representation (punched card, file on a hard
disk) is beyond the scope of the standard?

Quote:
> That's because the standard leaves the method by which an
> implementation transforms source files for use as Fortran
> programs up to that implementation.

Agreed, but is it correct to say that it is thus not
standard-conforming?

Quote:
> > I read once somewhere (probably in the UNIX HATER'S HANDBOOK) that it
> > was just an oversight to have tabs in make files, but this was not
> > changed due to backwards compatibility.  At the time, make had about 5
> > users.

> And, as I like to point out, that decision alone has cost "bazillions"
> of lost programmer hours due to bugs and such.  

It would be interesting to come up with a list of the 10 worst
programming mistakes, in terms of lost time.  I'm sure the make tabs
would be in these top ten.

Quote:
> "Practice random senselessness and act kind of beautiful."

Better than the other way around, I guess.  :)  :)

--

Nuffield Radio Astronomy Laboratories   Tel. ..... +44 1477 571 321 (ext. 297)
Jodrell Bank                            Fax ................. +44 1477 571 618
Macclesfield                            Telex ................. 36149 JODREL G
UK-Cheshire SK11 9DL                    Web .... http://www.jb.man.ac.uk/~pjh/

My opinions are not necessarily those of NRAL or the University of Manchester.



Wed, 18 Jun 1902 08:00:00 GMT  
 comma delimited file

Quote:




> > > However the system treats them, tabs in source code are DEFINITELY
> > > NONSTANDARD.  If it is `not covered by the standard' it is nonstandard.
> > > Tabs are not part of the Fortran character set.  

> > It really isn't an issue of standards conformance how source files
> > are processed for use as Fortran programs.  It is a quality-of-
> > implementation issue for an implementation (compiler); if it
> > doesn't process tabs in a canonical way, that means it won't
> > easily compile code that uses tabs.  But writing a tool
> > that replaces tabs with the appropriate number of spaces shouldn't
> > be too much of a hassle.

> Yes, I did write the tool.  But suppose instead of tabs the file had
> contained some other character which is not part of the Fortran
> character set, maybe one with the high bit set (i.e. 8-bit ASCII).  If
> THAT is standard-conforming, then anything is, and I can't see the
> difference between that and tab.  Just because tabs are commonly assumed
> to be equivalent to spaces doesn't give them any special (official)
> status with respect to Fortran.

Exactly.  FORTRAN 77 says basically nothing about ASCII, etc., just
which characters are part of the Fortran character set of any
conforming processor.  Spaces (blanks) are part of that; tabs are
not.  But since the transformation of system (source) files to
standard-defined Fortran code is entirely up to the implementation,
tabs might or might not end up being "standard-conforming" for that
implementation, and the same goes for any other character, including
spaces!  (Even lower-case *can* be thus conforming, as I pointed out.)

Quote:
> > And, even then, whatever your operating system uses to break
> > lines (newline character, record delimiters, etc.) ensures that
> > the source file is not, in fact, standard-conforming.

> Is this really in the same category?  The standard talks about lines and
> so on, but surely their representation (punched card, file on a hard
> disk) is beyond the scope of the standard?

Exactly, in that I'm trying to explain why *no computer file in
existence* is "standard-conforming", since the standard defines
no such thing.

That is, long ago on c.l.f, we used to have "fun" responding to
question like

  Is
        program foo
        [...]
        end
  standard-conforming?

by saying "no, because it's in lower case".

Then we began to realize the response was nonsensical, since, by the
same measures, the *upper-case* version is not standard conforming.
(It has newlines, or line breaks not blessed by the standard; it's
in ASCII, not blessed by the standard for source files; etc.)

It makes sense, then, to talk about source files being "standard-
conforming" vis-a-vis *reasonable* transformations that many, but
by no means all, Fortran implementations apply.  Lowercase to uppercase
is just too common now to complain about in source files; even an
implementation that doesn't transform it properly can be easily
enough worked around using a faily-quick-and-dirty preprocessor.

So I don't see much value in a statement like "tabs in source code
are DEFINITELY NONSTANDARD", because statements like "newlines in
source code are DEFINITELY NONSTANDARD", "ASCII in source code is
DEFINITELY NONSTANDARD", etc., are all just as true vis-a-vis strict
standards conformance.

And as soon as you get away from *strict* standards conformance,
you find out that newlines, tabs, ASCII, even lowercase are so
commonly accepted for transformation into standard-conforming
Fortran that, in effect, they *are* standard, and it's easy enough
to work around cases where one or two compilers don't render them so.

(In that you don't have to apply detailed knowledge of how the
program works to properly transform it.  However, there are
cases where that's not entirely true; exactly what does a
programmer intend by writing

10    FORMAT (' TEST\tVALUE')

where \t is *either* the ASCII TAB character *or*, literally,
backslash followed by lowercase `t'?  For example, if TAB, does
that mean the number of spaces to bring the *source file* cursor
to the next tab stop, or the *output file* cursor to the next
tab stop, or to output a literal tab in the output file?  But in
these cases, it is really up to the person trying to transform the
file for use on a new compiler to know what was intended; the
transformation mechanism itself rarely needs to have much inside
knowledge, once properly selected.)

Quote:
> > That's because the standard leaves the method by which an
> > implementation transforms source files for use as Fortran
> > programs up to that implementation.

> Agreed, but is it correct to say that it is thus not
> standard-conforming?

Which "it"?
--

"Practice random senselessness and act kind of beautiful."



Fri, 03 Nov 2000 03:00:00 GMT  
 comma delimited file

[ I hope I've got this attribution right (I'm using an article Craig
  Burley responded to because the original hasn't reached my site yet ]

Quote:
> I read once somewhere (probably in the UNIX HATER'S HANDBOOK) that it
> was just an oversight to have tabs in make files, but this was not
> changed due to backwards compatibility.  At the time, make had about 5
> users.

That's nothing; when we (I mean "we" in my previous job) received a shiny new
5*10^7 Dutch Guilders (about $ 2.5*10^7) Cray Y-MP8-something in the
beginning of the nineties, the sendmail.cf file that came with it contained a
space in a place where there should be only tabs (heh, heh).

`od' is your friend in such a case (after pouring over the sendmail docs for
hours, that is).

--

Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Phone: +31 346 214290; Fax: +31 346 214286



Fri, 03 Nov 2000 03:00:00 GMT  
 comma delimited file



Quote:



...
> Exactly, in that I'm trying to explain why *no computer file in
> existence* is "standard-conforming", since the standard defines
> no such thing....

And this deliberate lack of specification is appropriate for the
Fortran-language standards.

But.

It *is* an appropriate subject for operating-environment standards
such as POSIX.  IMNHO, POSIX damned well _should_ have defined what
a POSIX Fortran file means.  Sure, the consequence is that vendors
are then going to have to get it right, but that trouble is a lot
less than users have now under POSIX, having to deal with ump{*filter*}
different proprietary vendor-specific versions of Fortran-files.

The upshot is that one *cannot do* reasonably-functional portable I/O
in Fortran (expecially for scientific programming where one cannot get
away with dinky little sequential ASCII files (at least _that_ is
standardized) :-) ) and is forced into multi-language programming
with the I/O probably in C -- yet another exercise in proprietary,
vendor-specific coding.

fwiw.


MCNC Environmental Programs                      phone: (919)248-9241
North Carolina Supercomputing Center               fax: (919)248-9245
3021 Cornwallis Road                                  P. O. Box 12889
Research Triangle Park, N. C.  27709-2889                         USA
"My opinions are my own, and I've got *lots* of them!"



Fri, 03 Nov 2000 03:00:00 GMT  
 comma delimited file

Quote:


> > > But writing a tool
> > > that replaces tabs with the appropriate number of spaces shouldn't
> > > be too much of a hassle.

> > Yes, I did write the tool.

That's because you're using VMS - on Unix such a tool is part of the system
utilities (expand) :-)

Quote:
> Exactly.  FORTRAN 77 says basically nothing about ASCII, etc., just
> which characters are part of the Fortran character set of any
> conforming processor.  Spaces (blanks) are part of that; tabs are
> not.  But since the transformation of system (source) files to
> standard-defined Fortran code is entirely up to the implementation,
> tabs might or might not end up being "standard-conforming" for that
> implementation, and the same goes for any other character, including
> spaces!  (Even lower-case *can* be thus conforming, as I pointed out.)

Indeed, and Craig forgot to tell that this is the very reason the g77 manual
extensively discusses *how* the compiler interprets the contents of a file
until it reaches definitions that can be found in the Fortran Standard.

[ What is a line ?  How long is a line ?  What is BLANK ? etc ]

--

Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Phone: +31 346 214290; Fax: +31 346 214286



Sat, 04 Nov 2000 03:00:00 GMT  
 
 [ 12 post ] 

 Relevant Pages 

1. Export Clarion .DAT files to ASCII comma delimited files

2. Export Clarion .DAT files to ASCII comma delimited files

3. Parsing Comma delimited files in J

4. matching records in a comma delimited file

5. Comma delimited file problem

6. importing from a comma delimited file

7. Comma delimited file?

8. comma delimited file

9. Regular Expressions in Rexx to crack a comma delimited file

10. Help with Comma Delimited File

11. Writing Form Output to a Comma Delimited File

12. newbie needs a little help parsing a comma delimited file

 

 
Powered by phpBB® Forum Software