Home     |     .Net Programming    |     cSharp Home    |     Sql Server Home    |     Javascript / Client Side Development     |     Ajax Programming

Ruby on Rails Development     |     Perl Programming     |     C Programming Language     |     C++ Programming     |     IT Jobs

Python Programming Language     |     Laptop Suggestions?    |     TCL Scripting     |     Fortran Programming     |     Scheme Programming Language


 
 
Cervo Technologies
The Right Source to Outsource

MS Dynamics CRM 3.0

Fortran Programming Language

Avoiding Labels


Can this code be rewritten to avoid the label:

                open(unit=3, file='myData.txt')
                m=1
        do while (.true.)
         read(3,end=10,fmt=*)x(m),y1(m)
         m=m+1
        enddo
10             close(unit=3)

Thanks
Michael

On Jun 3, 6:29 pm, mich@athenavisual.com wrote:

> Can this code be rewritten to avoid the label:

>                 open(unit=3, file='myData.txt')
>                 m=1
>         do while (.true.)
>          read(3,end=10,fmt=*)x(m),y1(m)
>          m=m+1
>         enddo
> 10             close(unit=3)

> Thanks
> Michael

integer:: ios
...
open(unit=3, file='myData.txt')
m = 1
do
  read(3,fmt=*,iostat=ios) x(m),y1(m)
  if (ios < 0) exit
  m = m + 1
end do
close(unit=3)
On Jun 3, 11:46 am, highegg <high@gmail.com> wrote:

Thanks much
I appreciate the quick response

Michael

highegg <high@gmail.com> wrote:
> integer:: ios
> ...
> open(unit=3, file='myData.txt')
> m = 1
> do
>   read(3,fmt=*,iostat=ios) x(m),y1(m)
>   if (ios < 0) exit
>   m = m + 1
> end do
> close(unit=3)

While that is a pretty literal translation of teh surface of the
original code, I'd advise against doing it quite that way. I would
advocate at least changing the test to ios/=0 instead of ios<0.

With the ios<0 test, the code continues trying to read after
encountering an error. Reading after an error would violate the
standard. Worse, however, it has a good chance of becomming an infinite
loop, always reporting an error and never an eof.

Better might be to output an error message and stop if ios>0. That
probably more accurately mimics what the original code would do in that
case.

While I'm on the subject of making suggestions for this code, I'd
suggest a dimension limit check on any I/O loop like this. That applies
to the original code as well as the modified version.

--
Richard Maine                    | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle           |  -- Mark Twain

As far as I know, this won't handle the case where the read encounters
an error instead of an end-of-file.  You'd have to test for ios > 0 and
recover from the error or terminate the program.

I don't know if iostat values are portable.  If that's an issue, and
input errors are to be treated as catastrophic, then the 'end=<label>'
specifier might be the easiest (if not the most elegant) way of doing this.

(I assume the code checks for 'm' being out of bounds for 'x' or 'y1'.)

Louis

Louis Krupp <lkr@pssw.nospam.com.invalid> wrote:
> I don't know if iostat values are portable.

The distinction between 0, <0, and >0 is standard and portable.
Otherwise, specific values are not portable (although f2003 adds
portable way to tell what the eof and eor values are).

--
Richard Maine                    | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle           |  -- Mark Twain

On 3 jun, 20:56, nos@see.signature (Richard Maine) wrote:

> highegg <high@gmail.com> wrote:
> > integer:: ios
> > ...
> > open(unit=3, file='myData.txt')
> > m = 1
> > do
> >   read(3,fmt=*,iostat=ios) x(m),y1(m)
> >   if (ios < 0) exit
> >   m = m + 1
> > end do
> > close(unit=3)

[...]

> While I'm on the subject of making suggestions for this code, I'd
> suggest a dimension limit check on any I/O loop like this. That applies
> to the original code as well as the modified version.

As the OP is not using a dynamically allocated array, the
check for the dimension limit is very easy to do:

open(unit=3, file='myData.txt')

do m = 1,size(x)
    read(3,fmt=*,iostat=ios) x(m),y1(m)
    if (ios < 0) exit
    if (ios > 0) then
        write(*,*) 'Error reading data pair ',m
        stop
   endif
end do
close(unit=3)

Regards,

Arjen

Arjen Markus <arjen.mar@wldelft.nl> wrote:
> As the OP is not using a dynamically allocated array, the
> check for the dimension limit is very easy to do:
...
> do m = 1,size(x)
>     read(3,fmt=*,iostat=ios) x(m),y1(m)
>     if (ios < 0) exit
>     if (ios > 0) then
>         write(*,*) 'Error reading data pair ',m
>         stop
>    endif
> end do

Nothing unique to dynamically sized arrays there. It does assume that
the array size is set before this loop, as opposed to being adjusted to
accomdate the data being read; I suppose that's probably what you were
saying.

This simple method does avoid indexing the array out of bounds. However,
it does so by just ignoring any further data. That might be acceptable,
depending on the application. If you want to generate an error message
for that condition, it takes a little more work. In particular, you tend
to need to read into a temporary variable instead of directly into the
arrays because you need to try one read past the end of the array in
order to get the boundary condition right.

--
Richard Maine                    | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle           |  -- Mark Twain

On 4 jun, 16:56, nos@see.signature (Richard Maine) wrote:

Hm, yes, that is true - with "dynamically allocated arrays", I was
thinking
of arrays that get expanded during the loop to allow the new data to
be
stored.

Detecting extra data could be done by using a bound like "size(x)+1"
and
storing the data only if the loop index is lower than that. The main
advantage above the do loop without any condition is that you can not
go wrong with initialising or incrementing the index.

Regards,

Arjen

Add to del.icio.us | Digg this | Stumble it | Powered by Megasolutions Inc