Simulating non-standard Q character count edit descriptor
awgre...@earthlink.net
parameter (MAXLINE=10000)
character(MAXLINE) line
open(1,file='whatever',
access='sequential',form='formatted',action='read')
do
read(1,'(Q,A)',iostat=i) n,line(:n) !more efficient for lines much
smaller than MAXLINE
if (i/=0) exit
! real work here
enddo
end
Is there anyway to easily AND efficiently simulate the non-standard
character count (bytes-left-in-record) Q edit descriptor above with
standard F95 or maybe F2003 stream IO?
Al Greynolds
www.ruda.com
Michael Metcalf
<awgre...@earthlink.net> wrote in message
news:1163526118....@k70g2000cwa.googlegroups.com...
>
> Is there anyway to easily AND efficiently simulate the non-standard
> character count (bytes-left-in-record) Q edit descriptor above with
> standard F95 or maybe F2003 stream IO?
>
read(1,'(A)',iostat=i) line
n = len_trim(line)
?
Regards,
Mike Metcalf
Richard Maine
I suspect your efficiency concerns are unfounded. Presumably the
efficiency concern is that if you do this the trivial way, time will be
spent in blank padding line. However formatted I/O is so slow in
general, that I'd speculate that the time to blank pad a 10,000
character string is small compared to the formatted I/O in the first
place. When I see formatted I/O in conjunction with efficiency concerns,
the first comment is whether it can be done with unformatted. This
assumes, of course, that the time involved is really worth bothering
with anyway. It is fairly common to see people worrying about efficiency
of something that is too small to measure anyway, just because they are
used to worrying about it.
But, to more directly answer your question, assuming that the need is
legitimate, there are two methods within the standard. I won't bother to
try to write out code, as I'd mess something up doing it off the top of
my head, but the two basic ideas are
1. Use non-advancing input and the size= specifier. I think you'd have
to use an array of characters instead of a character string to make this
work. This is valid as of f90.
2. Again with non-advancing I/O, read a character at a time until you
hit an eor. While this avoids the blank-padding of line, I'd be
concerned (if efficiency was important) that there might be a lot of
per-read overhead for retrieving only one character per read. Yes, I
know that the system would no doubt buffer the low-level I/O, but
there's bound to be some overhead in setup per read statement also.
You could also use f2003 stream, as you suggested. But it is still the
same two basic methods - just on top of a stream open instead of a
sequential open. I don't think there would be a big difference in this
case.
--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
awgre...@earthlink.net
Michael Metcalf wrote:
> > Is there anyway to easily AND efficiently simulate the non-standard
> > character count (bytes-left-in-record) Q edit descriptor above with
> > standard F95 or maybe F2003 stream IO?
> >
> How about:
>
> read(1,'(A)',iostat=i) line
> n = len_trim(line)
Yes, this is what I started with but I found that the Q descriptor
version could read a large file with mostly short lines (but a few very
long lines) almost 3x times faster using IVF.
Al
robert....@sun.com
Richard Maine wrote:
> <awgre...@earthlink.net> wrote:
>
> > Given the following simple non-standard program:
> >
> > parameter (MAXLINE=10000)
> > character(MAXLINE) line
> > open(1,file='whatever',
> > access='sequential',form='formatted',action='read')
> > do
> > read(1,'(Q,A)',iostat=i) n,line(:n) !more efficient for lines much
> > smaller than MAXLINE
> > if (i/=0) exit
> > ! real work here
> > enddo
> > end
> >
> > Is there anyway to easily AND efficiently simulate the non-standard
> > character count (bytes-left-in-record) Q edit descriptor above with
> > standard F95 or maybe F2003 stream IO?
>
> I suspect your efficiency concerns are unfounded. Presumably the
> efficiency concern is that if you do this the trivial way, time will be
> spent in blank padding line. However formatted I/O is so slow in
> general, that I'd speculate that the time to blank pad a 10,000
> character string is small compared to the formatted I/O in the first
> place.
While I would agree with you in the case of most edit descriptors,
I disagree in this case. The A edit descriptor is about as fast as
moving characters in most implementations.
> When I see formatted I/O in conjunction with efficiency concerns,
> the first comment is whether it can be done with unformatted. This
> assumes, of course, that the time involved is really worth bothering
> with anyway. It is fairly common to see people worrying about efficiency
> of something that is too small to measure anyway, just because they are
> used to worrying about it.
True.
> But, to more directly answer your question, assuming that the need is
> legitimate, there are two methods within the standard. I won't bother to
> try to write out code, as I'd mess something up doing it off the top of
> my head, but the two basic ideas are
>
> 1. Use non-advancing input and the size= specifier. I think you'd have
> to use an array of characters instead of a character string to make this
> work. This is valid as of f90.
>
> 2. Again with non-advancing I/O, read a character at a time until you
> hit an eor. While this avoids the blank-padding of line, I'd be
> concerned (if efficiency was important) that there might be a lot of
> per-read overhead for retrieving only one character per read. Yes, I
> know that the system would no doubt buffer the low-level I/O, but
> there's bound to be some overhead in setup per read statement also.
I think both of of these alternatives will be much slower than the code
shown. I presume your first alternative would involve reading the
data under an A1 edit descriptor, That typically has significantly
higher overhead than reading the string under a single A edit
descriptor. As you note, the second alternative is likely to be
much worse.
Bob Corbett