Re: MODULEand USE versus Argument Passing

John Harper wrote:

E. Robert Tisdale wrote:

Global variables are *always* a bad idea.
Never pass function arguments through modules or common storage.

Really? Suppose I am using one of the NAG routines, e.g. d01akf,
to calculate integral from a to b of f(x,y) dx for various values of y. The NAG specification says (irrelevant detail omitted;
and REAL should be replaced by REAL(kind(1.0d0)) with many compilers)
SUBROUTINE d01akf(f, a, b, ...)
REAL f, a, b, ...
EXTERNAL f

and f must be declared as EXTERNAL
in the (sub)program from which d01akf is called
and it must be declared as a REAL(DP) function of one REAL(DP) variable, not two. 

I had thought the way to get y into f was by COMMON before f90
and by using a module nowadays.  What would Robert have me do?

In www.nag.com/numeric/fl/manual/pdf/D01/d01akf.pdf is NAG's manual for d01akf; its example of how to use d01akf uses an integer variable in COMMON to count the number of evaluations of the function f.

John Harper, School of Mathematics, Statistics and Computer Science, Victoria University, PO Box 600, Wellington, New Zealand
e-mail john.harper@xxxxxxxxx phone (+64)(4)463 5341 fax (+64)(4)463 5045 

This is a design flaw in d01akf.
NAG should have provided for the second argument

      real function f(x, y)
        real x, y
        end function f

and allowed you to pass the second argument to the integrator

      subroutine d01akf(f, y, a, b, ...)
        real            f, y, a, b, ...
        external        f

Actually, a better design would use a function object.
I don't have access to a Fortran 03 compiler yet
so I'll give an example in C++:

        class function {
        private:
          // representation
          float Y;
        public:
          // operators
          float operator()(float x) const {
            return f(x, Y);
            }
          // constructors
          virtual
          function(float y = 0.0) Y(y) { }
          };

which could be used like this:

        function f(13.0);
        d01akf(f, a, b, ...);

The function object itself knows the value of Y
and supplies it when d01akf invokes f(x) for some x.
The object oriented inheritance and run-time polymorphism features
were not supported in standard Fortran until Fortran 03.

This is a common pattern and I would appreciate it
if someone could provide an example in Fortran 03.
.

Relevant Pages

  • Re: When will this ng come to accept that Fortran needs to go "back to the future" ?
    ... Mandated backward compatibility is insuring fortran survival despite ... I fully agree with your comments about COMMON - used without tricks ... and if it isn't a nightmare for the compiler writer, ... Fortran programming - I never felt a real need for it - and I wrote ...
    (comp.lang.fortran)
  • Re: Strange Fortran version
    ... "ENTRY lable" was common in some Fortran IV subroutines and probably ... Fortran compilers (many were written as a higher exercise in M.SC tasks ...
    (comp.lang.fortran)
  • Re: When will this ng come to accept that Fortran needs to go "back to the future" ?
    ... Mandated backward compatibility is insuring fortran survival despite ... I fully agree with your comments about COMMON - used without tricks ... Fortran programming - I never felt a real need for it - and I wrote ... But I would support it if it can be done as a clean extension from the ...
    (comp.lang.fortran)
  • Re: keyword capitalization -- current practice
    ... with regards to capitalizing keywords in Fortran. ... I'm not convinced that you will find a single most common style. ... I've also seen styles where people capitalize the first letter of ...
    (comp.lang.fortran)
  • Re: equivalence with dummy arguments
    ... he is saying that one of the common uses of ... to argue that in "Fortran", equivalence is useful to reduce the ... number of arguments by equivalencing an array both in the caller ... > additional feature that - in more rare cases when derived types are available ...
    (comp.lang.fortran)