Fortran - calling subroutines

Author

calling subroutines

2004-07-09, 4:00 pm

HI

I am using the g77 compiler in a WinXP environment. From the main
program I call a subroutine several times. The problem is that
apparently the variables of the subroutine are not reset to zero each
time I use the call sentence and the reseting semms to be a little
arbitrary.

When I asked the subroutione to print out the variable produced by it
(which are sent back to the main program) the program works as should
be (the variables were reset each time the subprogram was called). In
the case where I did't print there was an error.

To my knowledge in FORTRAN each time you call a subprogram the
variables are set to zero unless you ask to SAVE the old values. Do
somebody here know if there is something incorrect with this windows
version of g77?

Thanks

CA

Michael Metcalf

2004-07-09, 4:00 pm

"CA" <aac62@yahoo.com> wrote in message
news:56275212.0407090755.41d710d0@posting.google.com...
> To my knowledge in FORTRAN each time you call a subprogram the
> variables are set to zero unless you ask to SAVE the old values

That is not true. Unless the variables appear in a DATA statement, their
values are simply undefined. There are compilers that set variables to zero
by default but that is not required by any standard (nor is it usually
desirable).

Regards,

Mike Metcalf

glen herrmannsfeldt

2004-07-09, 4:00 pm

Michael Metcalf wrote:

> "CA" <aac62@yahoo.com> wrote in message
> news:56275212.0407090755.41d710d0@posting.google.com...
>
[color=darkred]
> That is not true. Unless the variables appear in a DATA statement, their
> values are simply undefined. There are compilers that set variables to zero
> by default but that is not required by any standard (nor is it usually
> desirable).

If they are in a DATA statement, as far as I know they are only
guaranteed to be initialized once. If you change a variable
not in a SAVE statement, it may or may not be reinitialized
each time.

-- glen

Richard Maine

2004-07-09, 4:00 pm

glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:

> If they are in a DATA statement, as far as I know they are only
> guaranteed to be initialized once. If you change a variable
> not in a SAVE statement, it may or may not be reinitialized
> each time.

Formally, an initialized variable that has ever been modified is
undefined on entries after the first. The "undefined" includes the
possibilities that it might have retained the same value (as though
saved), been reinitialized, become random garbage, or be detected as
an error if you reference it. If you reference such an undefined
variable the code is illegal and anything is allowed; all of the
above-mentioned possibilities seem reasonably likely.

Note that as of f90, DATA implies SAVE. You can't have an
initialized variable that isn't saved.

--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain | experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain

2004-07-13, 3:57 am

Richard Maine <nospam@see.signature> wrote in message news:<m1eknlhvlf.fsf@macfortran.local>...
> glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
>
>
> Formally, an initialized variable that has ever been modified is
> undefined on entries after the first. The "undefined" includes the
> possibilities that it might have retained the same value (as though
> saved), been reinitialized, become random garbage, or be detected as
> an error if you reference it. If you reference such an undefined
> variable the code is illegal and anything is allowed; all of the
> above-mentioned possibilities seem reasonably likely.
>
> Note that as of f90, DATA implies SAVE. You can't have an
> initialized variable that isn't saved.

SO if I requiere the subroutine to do its job completely independent
of the main (depending only on the transferred arguments) do I need to
reset to zero all the variables somehow involved all the times the
subprogram is called?

Thanks for the above's follow ups

CA

Jan Vorbrüggen

2004-07-13, 9:01 am

> SO if I requiere the subroutine to do its job completely independent
> of the main (depending only on the transferred arguments) do I need to
> reset to zero all the variables somehow involved all the times the
> subprogram is called?

If your code assumes that they are zero before you start the computation,
yes. More generally, any local variable must appear on the left-hand side
of an assignment before you can use it on the right-hand side. If not,
your code is 1) not standard-conforming, 2) likely to produce inconsistent
results even on one platform, certainly when run on different platforms,
and 3) likely to produce other results tomorrow than today.

Jan

James Van Buskirk

2004-07-13, 9:01 am

"Jan Vorbrüggen" <jvorbrueggen-not@mediasec.de> wrote in message
news:2lhjj9FcptcbU1@uni-berlin.de...

> If your code assumes that they are zero before you start the computation,
> yes. More generally, any local variable must appear on the left-hand side
> of an assignment before you can use it on the right-hand side. If not,
> your code is 1) not standard-conforming, 2) likely to produce inconsistent
> results even on one platform, certainly when run on different platforms,
> and 3) likely to produce other results tomorrow than today.

Just for completeness, I thought I would mention that unsaved
variables of user-defined types with default initialization work
the previous poster seems to prefer.

--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end

Catherine Rees Lay

2004-07-13, 9:01 am

In article <2lhjj9FcptcbU1@uni-berlin.de>, Jan Vorbrüggen
<jvorbrueggen-not@mediasec.de> writes
>
>If your code assumes that they are zero before you start the computation,
>yes. More generally, any local variable must appear on the left-hand side
>of an assignment before you can use it on the right-hand side. If not,
>your code is 1) not standard-conforming, 2) likely to produce inconsistent
>results even on one platform, certainly when run on different platforms,
>and 3) likely to produce other results tomorrow than today.
>
> Jan

you forgot the corollary to 3) - it will invariably produce different
results or crash horribly if demonstrating to your
boss/supervisor/client.

Catherine.
--
Catherine Rees Lay
To email me, use my first name in front of the "at".

Sponsored Links