Home > Archive > Fortran > January 2006 > Subroutine question
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Subroutine question
|
|
| Random Programmer 2005-08-04, 9:04 am |
| Hello all. Lets say I have a section of code which is run multiple
times in a program in at least two separate parts of the main program.
I would like to put it into a subroutine, but the problem is that doing
so will require that I pass on a majority of the program's variables to
it. My subroutine's "Call" command ends up being several lines long!
I've thought about summarising the arrays being passed on to just
vectors with the data to be manipulated and other steps...but I think
this will end up being more CPU/memory intensive than just copying and
pasting the code twice instead of passing it on to a subroutine.
Is there any way around this? For example can I just set up my
subroutines so that they use all of the global variables in the
program?
Thanks.
| |
| Arjen Markus 2005-08-04, 9:04 am |
| Well, a solution would be to use an internal subroutine:
program aha
real :: x
x = 1.0
call mysub
x = 2.0
call mysub
contains
subroutine mysub
write(*,*) 'x= ', x
end subroutine mysub
end program
Internal subroutines/functions have access to the variables in the
"host" routine
(but not vice versa)
Another way (though that is uglier) is to put the code for that section
in a
separate file and include in two or more places.
In general: subroutine calls are cheap and you should not worry too
much about passing several arguments. (Only if the number gets very
large should you start worrying - about the maintainability, not the
performance)
Regards,
Arjen
| |
| Random Programmer 2005-08-04, 9:04 am |
| Ah! I didn't know that. Thanks.
What are the benefits of and external subroutine then, and why would
anyone want to use them?
| |
|
| I see two reasons:
1) exactly the opposite of what you want: you might not want to be able
to modify the variables from the host (hard to catch bugs will happen
if you do).
2) it is only possible to call this subroutine from that specific place
(i.e. your main program). If it is something general, you might also
want to call it from other subroutines.
Joost
| |
| Jugoslav Dujic 2005-08-04, 5:04 pm |
| Arjen Markus wrote:
| Well, a solution would be to use an internal subroutine:
Ooh, but there are FAR better ways:
1) use your favorite editor's copy/paste command and repeat
the code N-1 times, so that you get N identical blocks.
2) <x days later> Notice that you have to have the code
enhanced. Change it in one place and repeat step 1
N-2 times (why N-2? Because you forgot to do it one time.)
3) <y days later> Notice that the code misbehaves.
Find the bug :-).
It's all in spirit of the old saying "W s of coding can
save you hours of planning".
Of course, I'm kidding -- but these days I'm fighting quite
a lot with codes produced using the method above, so I couldn't
resist proposing the method... especially if the step 3 is done
by someone else :-).
--
Jugoslav
___________
www.geocities.com/jdujic
Please reply to the newsgroup.
You can find my real e-mail on my home page above.
| |
| meek@skyway.usask.ca 2005-08-04, 5:04 pm |
| In a previous article, "Random Programmer" <nonexistent2032@yahoo.co.uk> wrote:
>Ah! I didn't know that. Thanks.
>
>What are the benefits of and external subroutine then, and why would
>anyone want to use them?
>
reason one:
The same subroutine can be linked with other programs.
reason two: with complicated routines maybe complete isolation
both ways (except for param. list) is safer.
Reason 3: Some of us use older fortrans because of their
very nice (non-standard) features - for which internal
subroutines do not exist.
Chris
| |
|
| One option appears to have been missed. Consolidating related variables in
derived types will reduce the number of arguments that must be passed. This
option may also reduce clutter in other parts of the program.
"Random Programmer" <nonexistent2032@yahoo.co.uk> wrote in message
news:1123157134.444259.263990@g49g2000cwa.googlegroups.com...
> Hello all. Lets say I have a section of code which is run multiple
> times in a program in at least two separate parts of the main program.
>
> I would like to put it into a subroutine, but the problem is that doing
> so will require that I pass on a majority of the program's variables to
> it. My subroutine's "Call" command ends up being several lines long!
> I've thought about summarising the arrays being passed on to just
> vectors with the data to be manipulated and other steps...but I think
> this will end up being more CPU/memory intensive than just copying and
> pasting the code twice instead of passing it on to a subroutine.
>
> Is there any way around this? For example can I just set up my
> subroutines so that they use all of the global variables in the
> program?
>
> Thanks.
>
| |
| Dick Russell 2005-08-04, 5:04 pm |
| Prior to the availability of MODULE, a good solution would be to gather
into a named COMMON block all of the variables truly common to multiple
subroutines and put this into a separate file. Each subprogram needing
access to such common data would have an INCLUDE line to grab that file
at compile time. The modern way would be to put the same stuff into a
MODULE (a sort of superset of COMMON), and have a USE in each
subprogram needing access to the stuff.
| |
| Richard E Maine 2005-08-04, 5:04 pm |
| In article <1123162363.936023.137560@g14g2000cwa.googlegroups.com>,
"Joost" <jv244@cam.ac.uk> wrote:
> I see two reasons: [for using external procedures] ...
Joost left off what I consider to be the two biggest reasons for
external procedures
1. That was the only option in f77 and earlier (except for statement
functions, which are very, very limited). Thus if you are either working
with old code or writing something that needs to be usable by old code,
then you need to use external procedures.
2. That is how you interface with non-Fortran code.
I very rarely use external procedures in new f90/f95 code unless it is
for one of the above two reasons. The majority of my procedures are
module procedures, and most of the rest are internal procedures.
Modules (or common blocks if one is doing f77-style things) also provide
a way to share lots of variables among different procedures. However,...
From the limited information given, I suspect that the code in question
might benefit from work on organization. This is *FAR* from unusual. I
dare say that most codes could benefit from such work. The skills of
program organization are nontrivial and take quite a bit longer to learn
than the skills of basic, line-by-line coding. Of course, my information
here is very limited and thus my conclusion could be off anyway. But
needing to communicate excessive numbers of variables between procedures
is a classic sign or organizational "issues".
It is hard for me to give concise suggestions here on organization
issues. It *IS* a skill that takes time to learn. There are some general
guidelines, but you can't just read the guidelines and suddenly be a
good program organizer. Plus, I don't even know for sure that the code
in question needs such work.
--
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
| |
|
| Random Programmer wrote:
>
> What are the benefits of and external subroutine then, and why would
> anyone want to use them?
For the list of gazillion benefits, see
http://netlib.org
Had it not been for those, company like Mathworks and a slew of others
would not exist today. In other words, had the CCC (committee comic
club) "invented" prematurely, much, if not most, of that work would be
useless.
| |
|
| m@skyway.usask.ca wrote:
>
> reason one:
> The same subroutine can be linked with other programs.
corollary:
Subroutine can be developed and tested independently.
Actually, that's #1 reason, and "reason one" is its 1st corollary. :)
| |
| mcalhoun@ksu.edu 2005-08-04, 5:04 pm |
| Arjen Markus wrote:
Jugoslav Dujic <jdujic@yahoo.com> wrote:[color=darkred]
>Ooh, but there are FAR better ways:
>1) use your favorite editor's copy/paste command and repeat
> the code N-1 times, so that you get N identical blocks.
>....[snip]....
If one REALLY wants to include the identical code N times in the same
program, what's wrong with putting that code in a separate file and then
just INCLUDE that file wherever the code was wanted. A later requirement
to modify that code now requires modifying one file.
FWIW, I have my own system in which a preprocessor permits the definition
of separate file(s) in the main program:
:
DEFINE 'Separate.INC' ****************************************
Statements to be repeat-INCLUDEd go here
END DEFINE ****************************************
***********
:
INCLUDE 'Separate.INC'
:
INCLUDE 'Separate.INC'
etc.
--
--Myron A. Calhoun.
Five boxes preserve our freedoms: soap, ballot, witness, jury, and cartridge
PhD EE (retired). "Barbershop" tenor. CDL(PTXS). W0PBV. (785) 539-4448
NRA Life Member and Certified Instructor (Home Firearm Safety, Rifle, Pistol)
| |
| Arjen Markus 2005-08-05, 4:01 am |
| > From the limited information given, I suspect that the code in question
> might benefit from work on organization. This is *FAR* from unusual. I
> dare say that most codes could benefit from such work. The skills of
> program organization are nontrivial and take quite a bit longer to learn
> than the skills of basic, line-by-line coding.
Unless I have missed something, it seems to me that very few
publications (books, tutorials, ...) provide substantial information
about
these aspects. Oh yes, one reads of "refactoring" and there are tools
around to help you do the dirty work. But guidelines for setting up a
fair-
sized program (not the toys usually shown in text books)? I have seen
hardly anything!
If I am wrong, please tell me where to find such a book or other
publication.
Regards,
Arjen
| |
| meek@skyway.usask.ca 2005-08-05, 9:01 am |
| In a previous article, mcalhoun@ksu.edu wrote:
>Arjen Markus wrote:
>
>Jugoslav Dujic <jdujic@yahoo.com> wrote:
>
>
>If one REALLY wants to include the identical code N times in the same
>program, what's wrong with putting that code in a separate file and then
>just INCLUDE that file wherever the code was wanted. A later requirement
>to modify that code now requires modifying one file.
>
>FWIW, I have my own system in which a preprocessor permits the definition
>of separate file(s) in the main program:
> :
> DEFINE 'Separate.INC' ****************************************
> Statements to be repeat-INCLUDEd go here
> END DEFINE ****************************************
***********
> :
> INCLUDE 'Separate.INC'
> :
> INCLUDE 'Separate.INC'
>etc.
>--
>--Myron A. Calhoun.
It's the "separate file" part that's wrong (for me anyway).
Sometime in the future you will read your main program and
it won't make sense because it's not all there. Then you
will have to go chasing off through your directories
looking for the include files, which you may or may not find.
...yes the full path may be stated ,... but things do get lost.
Chris
| |
| Sarah Bergstrom 2005-08-05, 9:01 am |
| "Random Programmer" <nonexistent2032@yahoo.co.uk> wrote in message
news:1123157134.444259.263990@g49g2000cwa.googlegroups.com...
> Is there any way around this? For example can I just set up my
> subroutines so that they use all of the global variables in the
> program?
While many people think COMMON is a dirty word, I think this sort of case is
a perfectly resonable place for a COMMON block specification, i.e. global
variables. Just document carefully which variables are changed where.
Sarah
| |
| Dan Nagle 2005-08-06, 9:02 am |
| Hello,
On Fri, 5 Aug 2005 09:53:18 -0400, "Sarah Bergstrom"
<sbergstr@mathworks.com> wrote:
<snip requoted>
>While many people think COMMON is a dirty word, I think this sort of =
case is=20
>a perfectly resonable place for a COMMON block specification, i.e. =
global=20
>variables. Just document carefully which variables are changed where.
I don't think common is a dirty word. I don't think Fortran
has global variables of any kind. Variables in common, like variables
in modules, are known only where the common or module is referenced.
IMHO, that makes common or modules more like module variables
than global variables. Sorry to split hairs, and sorry to use
the word module with two meanings, but I think it's
an important point.
>Sarah=20
The only names which are global in Fortran are subprograms, modules,
and common block names. (Unit number values are also.) But there
are no global variables in Fortran.
--=20
Cheers!
Dan Nagle
Purple Sage Computing Solutions, Inc.
| |
| glen herrmannsfeldt 2005-08-06, 5:01 pm |
| Dan Nagle wrote:
(snip)
> I don't think common is a dirty word. I don't think Fortran
> has global variables of any kind. Variables in common, like variables
> in modules, are known only where the common or module is referenced.
(snip)
> The only names which are global in Fortran are subprograms, modules,
> and common block names. (Unit number values are also.) But there
> are no global variables in Fortran.
The variables are global, but the variable names aren't.
COMMON compiles pretty much like a static external structure
in some other languages. In many languages structure element
names also aren't global, even though the structure may be
referenced in different subprograms.
-- glen
| |
| Richard Maine 2005-08-06, 5:01 pm |
| In article <_4Odnc-NpK2hU2nfRVn-rA@comcast.com>,
glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:
> The variables are global, but the variable names aren't.
Not even the variables are really global. All that is global in a COMMON
other than the common block name is the storage. The mapping of
variables onto that storage is local. (To get even more picky, not even
the storage is global - the storage for different common blocks of the
same name is just associated. But I'll pass that bit by.)
For example, in one local instance of a COMMON, there might be a single
double precision variable where another instance of the same COMMON has
two real ones. So there isn't even agreement on the number of variables
involved.
This is among the kinds of things that makes COMMON a mess. It is
possible for a particular user to use COMMON in a way that is
disciplined and simple. But that's a choice of the user rather than the
way it is fundamentally defined in the standard. In the standard, COMMON
is full of strange quirks.
| |
| Sarah Bergstrom 2005-08-08, 5:03 pm |
|
"Dan Nagle" <dannagle@verizon.net> wrote in message
news:8119f1ldqasee3u1j0irrcq1l8khdm79jg@
4ax.com...
Hello,
On Fri, 5 Aug 2005 09:53:18 -0400, "Sarah Bergstrom"
<sbergstr@mathworks.com> wrote:
[color=darkred]
>I don't think common is a dirty word. I don't think Fortran
>has global variables of any kind. Variables in common, like variables
>in modules, are known only where the common or module is referenced.
Oh, I totally agree -- "global" is not quite a synonym for COMMON, but in
this context they can be used to serve the same function. And have a
similar risk -- sloppy programming and documenting can make for
hard-to-maintain and debug code, but that's no reason to abandon a useful
programming feature. *I* don't think COMMON or global are dirty words. Nor
GOTO. But sometimes I think I'm the only one. (Then again, I'm usually the
only one in the room who knows F77.)
Sarah (another F77 programmer younger than the standard itself.)
| |
|
| Dan Nagle wrote:
>
> I don't think common is a dirty word. I don't think Fortran
> has global variables of any kind. Variables in common, like variables
> in modules, are known only where the common or module is referenced.
It's the latter that makes common such a powerful feature - global on
demand. Common, afaik, was conceived to share data throughout the
universe with an option to call it whatever and wherever you like and
with *zero* overhead - while being invisible everywhere else.
See the light, try a concept of subglobal variable exchange, often
happens in big multi million liner mamas, with the primitive "global
variable" you had the audacity to compare to fortran common.
| |
| glen herrmannsfeldt 2005-08-09, 4:04 am |
| bv wrote:
(snip)
> It's the latter that makes common such a powerful feature - global on
> demand. Common, afaik, was conceived to share data throughout the
> universe with an option to call it whatever and wherever you like and
> with *zero* overhead - while being invisible everywhere else.
On machines that can directly address all of memory, which the early
Fortran machines could, yes, it is zero overhead.
Speed was very important to the authors of the first Fortran
compiler, when it was believed necessary to compete with assembly
programmers for execution speed.
For many machines now, COMMON is indirectly addressed, so there
is a little more overhead.
> See the light, try a concept of subglobal variable exchange, often
> happens in big multi million liner mamas, with the primitive "global
> variable" you had the audacity to compare to fortran common.
-- glen
| |
| Gordon Sande 2005-08-09, 9:03 am |
|
bv wrote:
> Dan Nagle wrote:
>
>
>
> It's the latter that makes common such a powerful feature - global on
> demand. Common, afaik, was conceived to share data throughout the
> universe with an option to call it whatever and wherever you like and
> with *zero* overhead - while being invisible everywhere else.
>
> See the light, try a concept of subglobal variable exchange, often
> happens in big multi million liner mamas, with the primitive "global
> variable" you had the audacity to compare to fortran common.
>
Back in prehistory when one still used computers by candlelight ;-)
one purpose of BLANK common was to reuse the memory used by the system
program that loaded your program. Since you then got the benefits of
whatever was left over there the initial state was not very reliable.
NAMEd common is a newfangled thing compared to the true benefits of
BLANK common. Then folks figured out how to make images of executables
and forgot how to cram things into little itty bitty memories. Why
folks probably no longer know how to recover from dropping a box of cards.
Fortunately all that is long past except for curious echoes now and
then.
| |
| mcalhoun@ksu.edu 2005-08-11, 4:01 am |
| >> I don't think common is a dirty word....
>....[snip]....
>See the light, try a concept of subglobal variable exchange, often
>happens in big multi million liner mamas, with the primitive "global
>variable" you had the audacity to compare to fortran common.
Or try using named COMMONs (which someone just barely mentioned)
so you can share variables subglobally between specified routines.
It's a bit of work, but the use of INCLUDEs can make it manageable.
--
--Myron A. Calhoun.
Five boxes preserve our freedoms: soap, ballot, witness, jury, and cartridge
PhD EE (retired). "Barbershop" tenor. CDL(PTXS). W0PBV. (785) 539-4448
NRA Life Member and Certified Instructor (Home Firearm Safety, Rifle, Pistol)
| |
| glen herrmannsfeldt 2005-08-22, 7:57 am |
| Gordon Sande wrote:
(snip)
> NAMEd common is a newfangled thing compared to the true benefits of
> BLANK common. Then folks figured out how to make images of executables
> and forgot how to cram things into little itty bitty memories. Why
> folks probably no longer know how to recover from dropping a box of cards.
Easy for those who put sequence numbers in columns 73-80. A quick run
through a card sorter will then fix it.
How many people actually put in sequence numbers?
-- glen
| |
| Richard E Maine 2005-08-22, 7:02 pm |
| In article <tvidnRB1NIR7C5TeRVn-2A@comcast.com>,
glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:
> Gordon Sande wrote:
>
> Easy for those who put sequence numbers in columns 73-80. A quick run
> through a card sorter will then fix it.
>
> How many people actually put in sequence numbers?
I used to. And I also once actually used them on a box of dropped cards.
--
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
| |
| Jan Vorbrüggen 2005-08-23, 7:57 am |
| >>How many people actually put in sequence numbers?
> I used to. And I also once actually used them on a box of dropped cards.
Ah yes. VMS even had a screen-based editor that used sequence numbers,
at least internally. When you inserted a new line between, say, lines 13
and 14, it became line 13.1 8-)...
Jan
| |
| meek@skyway.usask.ca 2005-08-23, 7:00 pm |
| In a previous article, =?ISO-8859-1?Q?Jan_Vorbr=FCggen?= <jvorbrueggen-not@mediasec.de> wrote:
>
>Ah yes. VMS even had a screen-based editor that used sequence numbers,
>at least internally. When you inserted a new line between, say, lines 13
>and 14, it became line 13.1 8-)...
>
> Jan
>
It still does.
Chris
| |
| glen herrmannsfeldt 2005-08-23, 7:00 pm |
| Jan Vorbrüggen wrote:
[color=darkred]
[color=darkred]
> Ah yes. VMS even had a screen-based editor that used sequence numbers,
> at least internally. When you inserted a new line between, say, lines 13
> and 14, it became line 13.1 8-)...
WYLBUR puts them in on submitted jobs, and by default on output
from the PUNCH command.
I don't remember ever adding them in on cards that I punched
by hand, though.
-- glen
| |
|
| Random Programmer wrote in message <1123157134.444259.263990@g49g2000cwa.googlegroups.com>...
>Hello all. Lets say I have a section of code which is run multiple
>times in a program in at least two separate parts of the main program.
>
>I would like to put it into a subroutine, but the problem is that doing
>so will require that I pass on a majority of the program's variables to
>it. My subroutine's "Call" command ends up being several lines long!
>I've thought about summarising the arrays being passed on to just
>vectors with the data to be manipulated and other steps...but I think
>this will end up being more CPU/memory intensive than just copying and
>pasting the code twice instead of passing it on to a subroutine.
>
>Is there any way around this? For example can I just set up my
>subroutines so that they use all of the global variables in the
>program?
Yes. Just make the subroutine an internal one.
>Thanks.
|
|
|
|
|