Manage external functions

Mike

unread,

Oct 24, 2008, 12:17:32 AM10/24/08

to

Hi

Is there a way to better manage some similar external functions as
input arguments in IMSL?
Let's say I use method1 and method2 in IMSL to solve the roots.
There should be different FUNCs for method 1 and method2. Currently I
create two projects for two methods and append the FUNC in the main
program, like:

proj1
module MyStuff1
contains
subroutine myMethod1()
call IMSLMethod1()
end module MyStuff1
program main
use imsl_stuff
use MyStuff
call IMSLMethod1()
end program main
FUNCTION FUNC()
================================
proj2
module MyStuff2
contains
subroutine myMethod2()
call IMSLMethod2()
end module MyStuff2
program main
use imsl_stuff
use MyStuff2
call IMSLMethod2()
end program main
FUNCTION FUNC() <==same FUNC name

I'd like to manage them better, since two projects contains similar
modules.
I also try to put FUNC into module MyStuff, however, if I use both
MuStuff modules
then may be two FUNCs will be used. That will be a bad idea.

Mike

unread,

Oct 24, 2008, 1:01:27 AM10/24/08

to

If I do :
program main
use imsl_stuff
use MyStuff1
use MyStuff2
call IMSLMethod1()

call IMSLMethod2()
end program main

FUNCTION FUNC() <==how to specify different FUNCs here?

thank you a million.

Mike

Arjen Markus

unread,

Oct 24, 2008, 2:41:45 AM10/24/08

to

> Mike- Tekst uit oorspronkelijk bericht niet weergeven -
>
> - Tekst uit oorspronkelijk bericht weergeven -

That sort of functionality has been around for a very long
time in Fortran. For instance (using Fortran 90 features):

program integrate_a_bit

call integrate( f, 1.0, 2.0, result )
call integrate( g, 1.0, 10.0, result )

containing
subroutine integrate( f, a, b, result )
real :: a, b, result
interface
real function f(x)
real :: x
end interface

! compute a rough approximation of the integral over [a,b]
do i = 1,10
xc = a + (i-0.5) * (b-a)/10.0
result = result + f(x)
enddo
result = result * (b-a)/10.0

end subroutine

real function f(x)
real :: x
f = x**2
end function

real function g(x)
real :: x
g = x*expr(-x)
end function

end program

The method: you pass the function as an argument

Regards,

Arjen

Mike

unread,

Oct 24, 2008, 4:21:59 AM10/24/08

to

Oh. The problem is the "f" function must be "f", I cannot modify it
to other names (It's defined by some library such as Numerical Recipe
or IMSL).
So two f? How to manage them, such that one f w.r.t. Method1 and
other f w.r.t. Method2?

Thanks.

Mike

Reinhold Bader

unread,

Oct 24, 2008, 4:46:59 AM10/24/08

to

Hello Mike,

Mike schrieb:

If only one of them is actually referenced, there should be no problem.
Otherwise, you could use the renaming feature to disambiguate:

use MyStuff2, only: IMSLMethod2, Func2 => Func
use MyStuff1, only: IMSLMethod1, Func1 => Func

If the references are *within* the modules only, there is no reason to
use the same name.

Regards
Reinhold

glen herrmannsfeldt

unread,

Oct 24, 2008, 7:08:06 AM10/24/08

to

Mike wrote:
(snip)

> Oh. The problem is the "f" function must be "f", I cannot modify it
> to other names (It's defined by some library such as Numerical Recipe
> or IMSL).
> So two f? How to manage them, such that one f w.r.t. Method1 and
> other f w.r.t. Method2?

Possible, but very rare.

The function name is passed to the called routine, possibly called f,
but it will actually call whatever function you supply.

Which NR or IMSL function are you using?

-- glen

Herman D. Knoble

unread,

Oct 24, 2008, 7:06:56 AM10/24/08

to

On Thu, 23 Oct 2008 23:41:45 -0700 (PDT), Arjen Markus <arjen....@wldelft.nl> wrote:

-|>
-|> - Tekst uit oorspronkelijk bericht weergeven -

-|

-|That sort of functionality has been around for a very long

-|
Arjen: Can internal functions (f and g) be used as actual arguments?

Thanks.
Skip

The method: you pass the function as an argument

-|
-|Regards,
-|
-|Arjen

Arjen Markus

unread,

Oct 24, 2008, 8:01:45 AM10/24/08

to

On 24 okt, 13:06, Herman D. Knoble <SkipKnobleL...@SPAMpsu.DOT.edu>
wrote:

If used in the same context, yes (or so I imagined), I have not
actually tried the code against a compiler.

Regards,

Arjen

Arjen Markus

unread,

Oct 24, 2008, 8:05:55 AM10/24/08

to

On 24 okt, 13:06, Herman D. Knoble <SkipKnobleL...@SPAMpsu.DOT.edu>
wrote:

> Arjen: Can internal functions (f and g) be used as actual arguments?
>
>

I would have thought you can (as integrate, f and g are all in
the same context), but g95 does not like it - even after correcting
a few stupid mistakes in the code.

So I guess, there is a need to introduce modules - I did not
want to do that for this small example, but ...

Regards,

Arjen

Arjen Markus

unread,

Oct 24, 2008, 8:30:38 AM10/24/08

to

I have to correct that conclusion:
Both gfortran and ifort do accept the corrected program.

It appears here in full:

program integrate_a_bit

call integrate( f, 1.0, 2.0, result )

call integrate( g, 1.0, 10.0, result )

contains

subroutine integrate( f, a, b, result )

real :: a, b, result
interface
real function f(x)
real :: x

end function
end interface

! compute a rough approximation of the integral over [a,b]

do i = 1,10

xc = a + (i-0.5) * (b-a)/10.0

result = result + f(x)

enddo

result = result * (b-a)/10.0

end subroutine

real function f(x)
real :: x
f = x**2
end function

real function g(x)
real :: x

g = x*exp(-x)
end function

end program

(The g95 version on my machine may be a trifle old ...)

Regards,

Arjen

Herman D. Knoble

unread,

Oct 24, 2008, 8:58:09 AM10/24/08

to

On Fri, 24 Oct 2008 05:30:38 -0700 (PDT), Arjen Markus <arjen....@wldelft.nl> wrote:

-|>
-|> Regards,
-|>
-|> Arjen

-|
-|I have to correct that conclusion:
-|Both gfortran and ifort do accept the corrected program.
-|
-|It appears here in full:

-|
-|program integrate_a_bit
-|

-| call integrate( f, 1.0, 2.0, result )
-| call integrate( g, 1.0, 10.0, result )
-|
-|contains

-| end function

-| end interface
-|
-| ! compute a rough approximation of the integral over [a,b]
-| do i = 1,10

-| xc = a + (i-0.5) * (b-a)/10.0
-| result = result + f(x)
-| enddo
-| result = result * (b-a)/10.0

-| g = x*exp(-x)

-|end function
-|
-|end program
-|

-|
-|(The g95 version on my machine may be a trifle old ...)

Arjen: the latest g95 compile gives:
C:\fort>g95 multiplefunc.f90
In file multiplefunc.f90:3

call integrate( f, 1.0, 2.0, result )

1
Error: Internal procedure 'f' at (1) cannot be used as an actual argument.

Using a module does work though.

Skip

rusi_pathan

unread,

Oct 24, 2008, 9:28:19 AM10/24/08

to

On Oct 24, 8:58 am, Herman D. Knoble <SkipKnobleL...@SPAMpsu.DOT.edu>
wrote:

Here's my understanding:
(1) Functions that are declared in the main program after 'contains'
cannot be passed as arguments
(2) Functions declared outside of the main program have to be declared
as external in the main program

program integrate_a_bit
real, external :: f, g

call integrate( f, 1.0, 2.0, result )

call integrate( g, 1.0, 10.0, result )

contains

subroutine integrate( f, a, b, result )

real :: a, b, result
interface
real function f(x)
real :: x

end function f
end interface

! compute a rough approximation of the integral over [a,b]

do i = 1,10

xc = a + (i-0.5) * (b-a)/10.0

result = result + f(x)

enddo

result = result * (b-a)/10.0

end subroutine integrate
end program integrate_a_bit

real function f(x)
real :: x
f = x**2

end function f

real function g(x)
real :: x
g = x*exp(-x)

end function g

dpb

unread,

Oct 24, 2008, 9:56:59 AM10/24/08

to

Mike wrote:
...

> Oh. The problem is the "f" function must be "f", I cannot modify it
> to other names (It's defined by some library such as Numerical Recipe
> or IMSL).

...

As Glen says, I don't think so.

I think you're misinterpreting the IMSL documentation where the FUNC
name is simply a dummy name for the user-supplied function.

For example, here's a cut 'n paste of one routine documentation...

> Usage
> CALL IVPRK (IDO, N, FCN, T, TEND, TOL, PARAM, Y)
> ....
> FCN — User-supplied SUBROUTINE to evaluate functions. The usage is CALL
> FCN (N, T, Y, YPRIME), where
> ...
> FCN must be declared EXTERNAL in the calling program.

FCN can be whatever you wish (F, and G in Arjen's example), you simply
reference the proper routine in the calling statement.

--

Richard Maine

unread,

Oct 24, 2008, 1:00:54 PM10/24/08

to

rusi_pathan <tabr...@gmail.com> wrote:

> (1) Functions that are declared in the main program after 'contains'
> cannot be passed as arguments

or after the contains in any subprogram either. They are called internal
functions.

> (2) Functions declared outside of the main program have to be declared
> as external in the main program

Only if they are indeed external functions (or dummy ones). Module
functions don't need and cannot have such a declaration. And the
declaration doesn't necessarily have to explicitly involve the keyword
"external". An interface body also declares the external attribute, as
does a procedure declaration statement. And again, there is nothing
particularly special about the main program here.

Both these well illustrate a point I've occasionally made when working
on the text of the standard itself. It tends to make text more
complicated (and prone to be wrong) when one talks too much in terms of
the syntax. It is usually better to discuss most requirements in terms
of the properties of things, and to make the discussion of what syntax
gives those properties a separate issue.

Admitedly, that adds one level of abstraction to the discussion, but
well... abstraction often makes things simpler.

There have been plenty of examples of wording proposed for the standard
that was incorrect because people referred too directly to syntax and
thus missed cases. For example, people talked about things that appear
in a SAVE statement instead of about things that had the SAVE attribute,
forgetting that there are multiple ways for something to get the SAVE
attribute. I recall some attempts to "fix up" such wording by making it
continually more complicated to cover more of the syntax possibilities
(I can offhand think of 3 ways other than appearing in a SAVE statement;
the fixups kept forgetting some; it sure makes the wording complicated
to include them all.)

In the above examples, the relevant properties are being an internal
function or an external function.

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

rusi_pathan

unread,

Oct 24, 2008, 7:08:34 PM10/24/08

to

On Oct 24, 1:00 pm, nos...@see.signature (Richard Maine) wrote:

Thanks for the clarification. I often learn a thing or two from your
posts/replies.

Mike

unread,

Oct 24, 2008, 8:40:57 PM10/24/08

to

I use powell in Numerical recipe. In brief,

subroutine powell(p,xi,....) !<== no func variable name here
external func !<== I am not supposed to modify this
name, right?
...
call linmin(...)
end

subroutine linmin(....)
external f1dim
....
call mnbrak(...., f1dim)
end

function f1dim(x)
....
xt=....x.....
f1dim=func(xt)
end

Since there is no FUNC argument in "powell", I cannot rename as other
name, e.g. FUNC1 or FUNC2.
Right? The key point is here.
Thank you and all for your help.

Mike

James Van Buskirk

unread,

Oct 25, 2008, 2:48:23 AM10/25/08

to

"Arjen Markus" <arjen....@wldelft.nl> wrote in message
news:69f299eb-6661-43c9...@v30g2000hsa.googlegroups.com...

> Both gfortran and ifort do accept the corrected program.

What version of gfortran do you have?
For my example, I get:

C:\gcc_mingw64a\clf\pass_internal>type pass_internal.f90
module mykinds
implicit none
integer, parameter :: dp = selected_real_kind(15,300)
end module mykinds

module funcs
use mykinds
implicit none
contains
recursive subroutine set_params(a,b,callback)
real(dp) a, b
interface
subroutine callback(fun)
implicit none
interface
pure function fun(x)
use mykinds
implicit none

real(dp) fun
real(dp), intent(in) :: x
end function fun
end interface
end subroutine callback
end interface
real(dp) a1, b1

a1 = a
b1 = b
call callback(fun)
contains
pure function fun(x)
real(dp) fun
real(dp), intent(in) :: x

fun = 1/(a1+b1*x**2)
end function fun
end subroutine set_params
end module funcs

module integrate
use mykinds
implicit none
contains
function simpson(fun,a,b,n)
real(dp) simpson
interface
function fun(x)
use mykinds
implicit none
real(dp) fun
real(dp), intent(in) :: x
end function fun
end interface
real(dp) a, b
integer n
integer n1
real(dp) h
real(dp) x
integer i

n1 = max(n,2)
n1 = n1+modulo(n1,2)
h = (b-a)/n1
x = a
simpson = fun(x)
do i = 1, n1-1
x = a+i*h
simpson = simpson+(3-(-1)**i)*fun(x)
end do
x = b
simpson = simpson+fun(x)
simpson = h*simpson/3
end function simpson
end module integrate

module CB_mod
use mykinds
use integrate
implicit none
contains
subroutine callback(fun)
interface
function fun(x)
use mykinds
implicit none
real(dp) fun
real(dp), intent(in) :: x
end function fun
end interface
integer npts
real(dp) a, b

npts = 200
a = 0
b = 1
write(*,*) 'Integral = ', simpson(fun,a,b,npts)
end subroutine callback
end module CB_mod

program pass_internal
use mykinds
use funcs
use integrate
use CB_mod
implicit none
real(dp) a, b

a = 3
b = 2
call set_params(a,b,callback)
write(*,*) 'Theory = ', atan(sqrt(b/a))/sqrt(a*b)
a = 3
b = -2
call set_params(a,b,callback)
write(*,*) 'Theory = ', atanh(sqrt(-b/a))/sqrt(-a*b)
end program pass_internal

C:\gcc_mingw64a\clf\pass_internal>x86_64-pc-mingw32-gfortran -std=f2008
pass_int
ernal.f90 -opass_internal
pass_internal.f90:30.23:

call callback(fun)
1
Error: Internal procedure 'fun' is not allowed as an actual argument at (1)
pass_internal.f90:103.12:

use funcs
1
Fatal Error: Can't open module file 'funcs.mod' for reading at (1): No such
file
or directory
x86_64-pc-mingw32-gfortran: Internal error: Aborted (program f951)
Please submit a full bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.

C:\gcc_mingw64a\clf\pass_internal>x86_64-pc-mingw32-gfortran -v
Using built-in specs.
Target: x86_64-pc-mingw32
Configured with:
../gcc/configure --prefix=/var/tmp/rt --with-sysroot=/var/tmp/r
t --host=i686-pc-mingw32 --target=x86_64-pc-mingw32 -q --silent
Thread model: win32
gcc version 4.4.0 20080921 (experimental) (GCC)

And also:

C:\gcc_mingw64a\clf\pass_internal>gfortran -std=f2008
pass_internal.f90 -opass_i
nternal
pass_internal.f90:30.23:

call callback(fun)
1
Error: Internal procedure 'fun' is not allowed as an actual argument at (1)
pass_internal.f90:103.12:

use funcs
1
Fatal Error: Can't open module file 'funcs.mod' for reading at (1): No such
file
or directory
gfortran: Internal error: Aborted (program f951)
Please submit a full bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.

C:\gcc_mingw64a\clf\pass_internal>gfortran -v
Built by Equation Solution (http://www.Equation.com).
Using built-in specs.
Target: x86_64-pc-mingw32
Configured with:
../gcc-4.4-20081017-mingw/configure --host=x86_64-pc-mingw32 --
build=x86_64-unknown-linux-gnu --target=x86_64-pc-mingw32 --prefix=/home/gfortra
n/gcc-home/binary/mingw32/native/x86_64/gcc/4.4-20081017 --with-gmp=/home/gfortr
an/gcc-home/binary/mingw32/native/x86_64/gmp --with-mpfr=/home/gfortran/gcc-home
/binary/mingw32/native/x86_64/mpfr --with-sysroot=/home/gfortran/gcc-home/binary
/mingw32/cross/x86_64/gcc/4.4-20081017 --with-gcc --with-gnu-ld --with-gnu-as
--
disable-shared --disable-nls --disable-tls --enable-libgomp --enable-languages=c
,fortran --enable-threads=win32 --disable-win32-registry
Thread model: win32
gcc version 4.4.0 20081017 (experimental) (GCC)

But with ifort:

C:\gcc_mingw64a\clf\pass_internal>ifort pass_internal.f90
Intel(R) Fortran Compiler for Intel(R) EM64T-based applications, Version 9.1
Build 20061104
Copyright (C) 1985-2006 Intel Corporation. All rights reserved.

-out:pass_internal.exe
-subsystem:console
pass_internal.obj

C:\gcc_mingw64a\clf\pass_internal>pass_internal
Integral = 0.279535444073994
Theory = 0.279535444073461
Integral = 0.467940656716492
Theory = 0.467940655051785

The capability of passing an internal procedure as an actual argument
is an extension to f95 and f03 (Note 12.12 in f95, Note 12.16 in f03)
which ifort has always implemented. I think that it is standard in
f08 (yes -- see Note 12.19) and I think that it was intended to
implement this feature in gfortran as a consequence of its upcoming
standardization. One point of the feature is that it enables
passing parameters to the function to be integrated in a potentially
thread-safe way, as in my example above.

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

George

unread,

Oct 25, 2008, 6:03:57 AM10/25/08

to

On Sat, 25 Oct 2008 00:48:23 -0600, James Van Buskirk wrote:

> module funcs
> use mykinds
> implicit none
> contains
> recursive subroutine set_params(a,b,callback)
> real(dp) a, b
> interface
> subroutine callback(fun)
> implicit none
> interface
> pure function fun(x)
> use mykinds
> implicit none

I'm gonna guess that this is a callback function done in fortran, which is
not the idiom I know for this.

Can someone say a few words on what this all means?
--
George

Faith crosses every border and touches every heart in every nation.
George W. Bush

Richard Maine

unread,

Oct 25, 2008, 12:55:12 PM10/25/08

to

James Van Buskirk <not_...@comcast.net> wrote:

> The capability of passing an internal procedure as an actual argument
> is an extension to f95 and f03 (Note 12.12 in f95, Note 12.16 in f03)
> which ifort has always implemented. I think that it is standard in
> f08 (yes -- see Note 12.19)

A slight nit. Insert "proposed to be" or simillar disclaimer in front of
"standard in f08". F08 isn't yet approved. Technical changes on that
order have quite regularly been made as late in the process as f08 is
now. I don't have any particular reason to suspect a change in this. I'm
just mentioning the nit to try to forestall too much in the way of false
assumptions of finality. People have been bitten by that in the past.
Compiler vendors have even been bitten by implementing draft features
and then getting stuck with supporting them in both the draft form and
the distinctly different final form. (Ask Steve about the f77 parameter
statement).

--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.

Mike

unread,

Oct 26, 2008, 8:02:06 PM10/26/08

to

On Oct 25, 2:48 pm, "James Van Buskirk" <not_va...@comcast.net> wrote:
> "Arjen Markus" <arjen.mar...@wldelft.nl> wrote in message

Sorry, I forgot to mention that I use Intel Visual Fortran and Visual
Studio 2008(as IDE).

Mike

unread,

Oct 27, 2008, 4:28:13 AM10/27/08

to

Sorry, but I think google updates so slowly.

Mike

Arjen Markus

unread,

Oct 28, 2008, 5:02:53 AM10/28/08

to

On 25 okt, 07:48, "James Van Buskirk" <not_va...@comcast.net> wrote:
> "Arjen Markus" <arjen.mar...@wldelft.nl> wrote in message

>
> news:69f299eb-6661-43c9...@v30g2000hsa.googlegroups.com...
>
> > Both gfortran and ifort do accept the corrected program.
>
> What version of gfortran do you have?
> For my example, I get:
>
> C:\gcc_mingw64a\clf\pass_internal>type pass_internal.f90

I have used gfortran 4.0.2 on Linux (gcc version 4.0.2 20051130 (Red
Hat 4.0.2-14.EL4)). To make the program work I had to correct a few
mistakes (that is what you get when you do not print the output ;))
and - and that is a compiler issue, I guess - I had to rename the
function f in the integrate subroutine to something other than f or g.

Version 4.3.0 does indeed complain about the use of the internal
functions, so it may have been an oversight in the compiler rather
than a possibly-defined-feature-from-F2008.

(As version 4.0.2 is really old, I do not think it makes sense to
report the confusion over f.)

Regards,

Arjen