Home > Archive > Fortran > November 2004 > problem with function as argument of procedure
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 |
problem with function as argument of procedure
|
|
| Phillip Helbig---remove CLOTHES to reply 2004-11-14, 3:55 am |
| I've been away from Fortran for a while (but am getting back to it), so
I hope someone can spot my obvious error.
I want to numerically integrate a function. Here's some pseudocode:
MODULE Q_FUNC
PRIVATE
PUBLIC Q
CONTAINS
FUNCTION Q(X)
Q = BLABLABLA(X)
END FUNCTION Q
END MODULE Q_FUNC
PROGRAM MAIN
USE Q_FUNC
INTEGRAL = INTEGRATOR(Q,START,END)
END PROGRAM MAIN
INTEGRATOR contains an INTERFACE for its dummy function argument. Q is
defined to correspond to this exactly.
The error I am gettting is:
%F90-E-ERROR, The characteristics of the associated actual function
result differ from the characteristics of the dummy function result.
(12.4.1.2, 12.2.2) [Q]
This is the DEC/Compaq/HP compiler on VMS (Alpha of course).
(I REALLY like the references to the standard in the error message; I
had a look in the standard but it doesn't help me here.)
My main question is, how can this even be possible? The MAIN program
has access to Q via USE association.
Perhaps I don't understand the error message well enough.
It seems to me that the interface to Q_FUNC from MAIN is explicit, since
it is accessed via USE association.
Q_FUNC and MAIN are in the same file. Surely I don't have to compile
Q_FUNC separately first to get this to work?
(On a related note, my gut feeling is that in this case an internal
procedure would be more appropriate for Q_FUNC, but this is not allowed
(according to M&R, because of the way internal procedures might be
implemented); has this restriction been relaxed in Fortran 2003? It
seems to me that a MODULE used by just one program is a bit of overkill
(which is why I want to include it in the same file, to make it clear
that it is just a one-off thing for the function I want to integrate).)
| |
| Phillip Helbig---remove CLOTHES to reply 2004-11-14, 3:56 pm |
| In article <cn72bi$cuk$1@online.de>, helbig@astro.multiCLOTHESvax.de
(Phillip Helbig---remove CLOTHES to reply) writes:
> I've been away from Fortran for a while (but am getting back to it), so
> I hope someone can spot my obvious error.
>
> I want to numerically integrate a function. Here's some pseudocode:
Here's some real code which has the same problem, using NUMERICAL
RECIPES integration routines. These are the Fortran90 versions; I've
successfully used the Fortran77 ones, so know what I'm doing in general.
Thus, it seems that I am missing something in Fortran90/95, or there is
a bug in the compiler. Note that, in contrast to the Fortran77 case,
the user-supplied function to be integrated is in a module used by the
main program, as opposed to being an external function.
MODULE Q_TEST
USE NRTYPE
CONTAINS
FUNCTION Q(Z)
! same error whether using the commented-out lines or the two following
! them, so the problem is not the fancy dimension stuff
!REAL(SP), DIMENSION(:), INTENT(IN) :: Z
!REAL(SP), DIMENSION(SIZE(Z)) :: Q
REAL(SP) :: Z
REAL(SP) :: Q
Q = 1.0/(1+Z)**3 ! the real integrand is more complicated :-)
END FUNCTION Q
END MODULE Q_TEST
PROGRAM TEST
USE Q_FUNC
USE NRTYPE
USE NR, ONLY: QTRAP, QSIMP, QROMB
IMPLICIT NONE
REAL(SP) :: INTEGRAL, A, B
READ*, A, B
INTEGRAL = QTRAP(Q,A,B)
INTEGRAL = QSIMP(Q,A,B)
INTEGRAL = QROMB(Q,A,B)
END PROGRAM TEST
The error messages are like:
%F90-E-ERROR, The characteristics of the associated actual function
result differ from the characteristics of the dummy function result.
(12.4.1.2, 12.2.2) [Q]
There must be some simple change which will get rid of the error message
above!
(I like the references to the standard in the error message, but they
don't help me here.)
| |
| Ron Shepard 2004-11-14, 3:56 pm |
| In article <cn72bi$cuk$1@online.de>,
helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES
to reply) wrote:
> I've been away from Fortran for a while (but am getting back to it), so
> I hope someone can spot my obvious error.
>
> I want to numerically integrate a function. Here's some pseudocode:
>
> MODULE Q_FUNC
> PRIVATE
> PUBLIC Q
> CONTAINS
> FUNCTION Q(X)
> Q = BLABLABLA(X)
> END FUNCTION Q
> END MODULE Q_FUNC
>
> PROGRAM MAIN
> USE Q_FUNC
> INTEGRAL = INTEGRATOR(Q,START,END)
> END PROGRAM MAIN
>
> INTEGRATOR contains an INTERFACE for its dummy function argument. Q is
> defined to correspond to this exactly.
>
> The error I am gettting is:
>
> %F90-E-ERROR, The characteristics of the associated actual function
> result differ from the characteristics of the dummy function result.
> (12.4.1.2, 12.2.2) [Q]
>
> This is the DEC/Compaq/HP compiler on VMS (Alpha of course).
>
> (I REALLY like the references to the standard in the error message; I
> had a look in the standard but it doesn't help me here.)
>
> My main question is, how can this even be possible? The MAIN program
> has access to Q via USE association.
>
> Perhaps I don't understand the error message well enough.
>
> It seems to me that the interface to Q_FUNC from MAIN is explicit, since
> it is accessed via USE association.
>
> Q_FUNC and MAIN are in the same file. Surely I don't have to compile
> Q_FUNC separately first to get this to work?
This is compiler specific, but I think what you have will probably
work alright. That is, when the module q_func appears first in the
file, then it should be available for the program which appears
later in the file. I've used compilers for which the other order
would not work.
As to the error, I think your problem is that the interface
specified within INTEGRATOR for the dummy function is not consistent
with the actual function interface. Since you do not show this
interface declaration in your post, we cannot know this, but that is
what the error message is saying.
$.02 -Ron Shepard
| |
| Rich Townsend 2004-11-14, 3:56 pm |
| Phillip Helbig---remove CLOTHES to reply wrote:
> In article <cn72bi$cuk$1@online.de>, helbig@astro.multiCLOTHESvax.de
> (Phillip Helbig---remove CLOTHES to reply) writes:
>
>
>
>
> Here's some real code which has the same problem, using NUMERICAL
> RECIPES integration routines. These are the Fortran90 versions; I've
> successfully used the Fortran77 ones, so know what I'm doing in general.
> Thus, it seems that I am missing something in Fortran90/95, or there is
> a bug in the compiler. Note that, in contrast to the Fortran77 case,
> the user-supplied function to be integrated is in a module used by the
> main program, as opposed to being an external function.
>
> MODULE Q_TEST
> USE NRTYPE
> CONTAINS
> FUNCTION Q(Z)
> ! same error whether using the commented-out lines or the two following
> ! them, so the problem is not the fancy dimension stuff
> !REAL(SP), DIMENSION(:), INTENT(IN) :: Z
> !REAL(SP), DIMENSION(SIZE(Z)) :: Q
> REAL(SP) :: Z
> REAL(SP) :: Q
> Q = 1.0/(1+Z)**3 ! the real integrand is more complicated :-)
> END FUNCTION Q
> END MODULE Q_TEST
>
> PROGRAM TEST
> USE Q_FUNC
> USE NRTYPE
> USE NR, ONLY: QTRAP, QSIMP, QROMB
> IMPLICIT NONE
> REAL(SP) :: INTEGRAL, A, B
> READ*, A, B
> INTEGRAL = QTRAP(Q,A,B)
> INTEGRAL = QSIMP(Q,A,B)
> INTEGRAL = QROMB(Q,A,B)
> END PROGRAM TEST
>
> The error messages are like:
>
> %F90-E-ERROR, The characteristics of the associated actual function
> result differ from the characteristics of the dummy function result.
> (12.4.1.2, 12.2.2) [Q]
>
> There must be some simple change which will get rid of the error message
> above!
>
> (I like the references to the standard in the error message, but they
> don't help me here.)
>
The problem is that your module is named 'Q_TEST', but in the main
program you use 'Q_FUNC'. This means that the Q function isn't getting
defined (or rather, doesn't have an explicit interface) in the main program.
Why the compiler isn't producing an error, regarding the non-existence
of the Q_FUNC module, is beyond me. Maybe the error gets quashed by the
one you find above; but this is an example of poor
quality-of-implementation. Which compiler is this?
cheers,
Rich
--
Dr Richard H D Townsend
Bartol Research Institute
University of Delaware
[ Delete VOID for valid email address ]
| |
| Phillip Helbig---remove CLOTHES to reply 2004-11-14, 3:56 pm |
| In article <cn81fj$seg$1@scrotar.nss.udel.edu>, Rich Townsend
<rhdt@barVOIDtol.udel.edu> writes:
> The problem is that your module is named 'Q_TEST', but in the main
> program you use 'Q_FUNC'. This means that the Q function isn't getting
> defined (or rather, doesn't have an explicit interface) in the main program.
Sorry, that's a red herring caused by changing long variable names to
short ones to make the example clearer. In the real code, the module
name and that in the USE statement are the same.
| |
| Phillip Helbig---remove CLOTHES to reply 2004-11-14, 3:56 pm |
| In article <cn7qdu$ah4$1@online.de>, helbig@astro.multiCLOTHESvax.de
(Phillip Helbig---remove CLOTHES to reply) writes:
> ! same error whether using the commented-out lines or the two following
> ! them, so the problem is not the fancy dimension stuff
> !REAL(SP), DIMENSION(:), INTENT(IN) :: Z
> !REAL(SP), DIMENSION(SIZE(Z)) :: Q
> REAL(SP) :: Z
> REAL(SP) :: Q
Sorry, typed too quickly here. The code above produces:
%F90-E-ERROR, The shape matching rules of actual arguments and dummy
arguments have been violated. [Q]
This is confusing as well, though; surely a rank-zero array should be
compatible with a scalar?
| |
| James Van Buskirk 2004-11-14, 8:56 pm |
| "Phillip Helbig---remove CLOTHES to reply" <helbig@astro.multiCLOTHESvax.de>
wrote in message news:cn7qdu$ah4$1@online.de...
> MODULE Q_TEST
> USE NRTYPE
> CONTAINS
> FUNCTION Q(Z)
> ! same error whether using the commented-out lines or the two following
> ! them, so the problem is not the fancy dimension stuff
> !REAL(SP), DIMENSION(:), INTENT(IN) :: Z
> !REAL(SP), DIMENSION(SIZE(Z)) :: Q
> REAL(SP) :: Z
> REAL(SP) :: Q
> Q = 1.0/(1+Z)**3 ! the real integrand is more complicated :-)
> END FUNCTION Q
> END MODULE Q_TEST
If the interface is anything like:
http://www.library.cornell.edu/nr/b...pdf/chap4f9.pdf
then changing the declaration of Q and Z above simply can't work.
QTRAP will pass an array descriptor by reference, and your function
has to know what to do with it. BTW, CVF, and so I would suspect
all Compaq F90+ compilers, accepts internal functions as actual
arguments. A couple of students just came in so I can't debug any
further now... eid mubarak!
--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end
| |
| Phillip Helbig---remove CLOTHES to reply 2004-11-14, 8:56 pm |
| In article <Q8Pld.96902$R05.63049@attbi_s53>, "James Van Buskirk"
<not_valid@comcast.net> writes:
> If the interface is anything like:
>
> http://www.library.cornell.edu/nr/b...pdf/chap4f9.pdf
>
> then changing the declaration of Q and Z above simply can't work.
> QTRAP will pass an array descriptor by reference, and your function
> has to know what to do with it.
That's true; I typed too quickly in my other post; a different error
message occurs.
> BTW, CVF, and so I would suspect
> all Compaq F90+ compilers, accepts internal functions as actual
> arguments.
Perhaps, but it's non-standard, so I don't want to mess with it!
| |
| James Van Buskirk 2004-11-15, 3:57 am |
| "Phillip Helbig---remove CLOTHES to reply" <helbig@astro.multiCLOTHESvax.de>
wrote in message news:cn8k8i$bf7$1@online.de...
> In article <Q8Pld.96902$R05.63049@attbi_s53>, "James Van Buskirk"
> <not_valid@comcast.net> writes:
[color=darkred]
[color=darkred]
[color=darkred]
> That's true; I typed too quickly in my other post; a different error
> message occurs.
OK, I tried messing with your problem a little. I wrote an nr.f90
file that contained the missing procedures and parameters like
SP, I4B, NPAR_ARTH, NPAR2_ARTH, arth, trapzd, and qtrap. Since
this is plagiarized from the NR web page and I assume you have
all this anyhow, I will leave it to your imagination. However,
you can see the new nr_test.f90 file:
! nr_test.f90
MODULE Q_TEST
USE NRTYPE
CONTAINS
FUNCTION Q(Z)
! same error whether using the commented-out lines or the two
following
! them, so the problem is not the fancy dimension stuff
REAL(SP), DIMENSION(:), INTENT(IN) :: Z
REAL(SP), DIMENSION(SIZE(Z)) :: Q
!REAL(SP) :: Z
!REAL(SP) :: Q
Q = 1.0/(1+Z)**3 ! the real integrand is more complicated :-)
END FUNCTION Q
END MODULE Q_TEST
PROGRAM TEST
USE Q_TEST
USE NRTYPE
USE NR, ONLY: QTRAP
IMPLICIT NONE
REAL(SP) :: INTEGRAL, A, B
write(*,'(a)',advance='no') 'Enter the value of A:> '
read(*,*) A
write(*,'(a)',advance='no') 'Enter the value of B:> '
read(*,*) B
INTEGRAL = QTRAP(Q,A,B)
write(*,*) integral
END PROGRAM TEST
Results with LF95 5.70f:
C:\LF9556\James\clf\nr_test>nr_test
nter the value of A:> 1
Enter the value of B:> 3
9.37500149E-02
Results with CVF 6.6C:
C:\LF9556\James\clf\nr_test>nr_test
Enter the value of A:> 1
Enter the value of B:> 3
9.3750015E-02
Result with Calculator:
0.09375
--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end
| |
| Phillip Helbig---remove CLOTHES to reply 2004-11-15, 8:56 am |
| In article <0UYld.41881$5K2.40161@attbi_s03>, "James Van Buskirk"
<not_valid@comcast.net> writes:
> OK, I tried messing with your problem a little. I wrote an nr.f90
> file that contained the missing procedures and parameters like
> SP, I4B, NPAR_ARTH, NPAR2_ARTH, arth, trapzd, and qtrap. Since
> this is plagiarized from the NR web page and I assume you have
> all this anyhow, I will leave it to your imagination. However,
> you can see the new nr_test.f90 file:
> Results with LF95 5.70f:
> C:\LF9556\James\clf\nr_test>nr_test
> nter the value of A:> 1
> Enter the value of B:> 3
> 9.37500149E-02
>
> Results with CVF 6.6C:
> C:\LF9556\James\clf\nr_test>nr_test
> Enter the value of A:> 1
> Enter the value of B:> 3
> 9.3750015E-02
>
> Result with Calculator:
> 0.09375
Since the code above is essentially the same as my own, are you saying
the code is correct and the compiler is wrong to give an error?
| |
| James Van Buskirk 2004-11-15, 3:59 pm |
| "Phillip Helbig---remove CLOTHES to reply" <helbig@astro.multiCLOTHESvax.de>
wrote in message news:cn9pii$1rv$1@online.de...
> Since the code above is essentially the same as my own, are you saying
> the code is correct and the compiler is wrong to give an error?
I can make no such conclusion from the information you have supplied.
CVF and Compaq Fortran for Open VMS are pretty closely related
products, I would think, especially regarding the front-end where
your problems are occurring. If you want, I can email you my nr.f90
file that I am hesitant to post in an open forum -- just set your
compiler for T_FLOAT rather than D_FLOAT or G_FLOAT and email me if
you want to test my full example on your machine. From your response
I assume that you tested my nr_test.f90 file in the context of your
machine and environment of NR code? Have you tried zipping up a
fully compilable, self contained example and tried running it through
Lahey's code checker? If you get errors with my example and your
example is passed by Lahey's code checker that might lead one to
believe that Compaq is wrong, but I would still not be 100% sure
about that conclusion: CVF (and likely Compaq) builds data structures
at compile time that enable it to do signature matching for procedure
arguments in a way that most other compilers can't. It will spit out
errors at compile time for mismatched procedure arguments when
competitors will have difficult-to-pin-down runtime errors. On the
other hand, you can get it to generate internal compiler errors when
you make it tricky to actually compare dummy and actual arguments.
As far as whether what you have is a compiler bug, that's kind of
a toss-up in my perception. What I would really like to see is a
complete (free from NR code) example that produces a compile-time
error on Compaq Fortran but passes the code checker at
http://www.lahey.com . Forum participants could then inspect the
example and determine whether you really have a mismatch or Compaq
is malfunctioning.
--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end
| |
| Richard E Maine 2004-11-15, 3:59 pm |
| helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) writes:
> I want to numerically integrate a function. Here's some pseudocode:
.....
Sorry, but I think I'm going to duck out of further replies to this
thread. You submitted the same thing both here (clf newsgroup) and to
the comp.fortran90 mailing list. Both seem to have generated
substantial threads in reply. This causes the same points to be made
in both places, which gets confusing and makes it take a lot more
time. It is just too much trouble for me to keep track of what was
said by whom where, and how to reply in reasonable context when I've
lost track of which pieces go with which context. Heck, postings
crossing in the "mail" can make things a bit confusing even when
restricted to a single forum.
I'm afraid I started reading here and then just got lost trying to figure
out what things I had already read, how the replies fit in, etc. Then
I just deleted the rest of the postings from my browser. Sorry, but I
need to get onto other things and this makes it take too much more time.
Simultaneous posting in multiple forums doesn't always improve the
odds of getting good replies.
--
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
| |
| Phillip Helbig---remove CLOTHES to reply 2004-11-15, 8:56 pm |
| In article <8v5md.340543$wV.212483@attbi_s54>, "James Van Buskirk"
<not_valid@comcast.net> writes:
> What I would really like to see is a
> complete (free from NR code) example
I'll write one tomorrow...
> that produces a compile-time
> error on Compaq Fortran but passes the code checker at
> http://www.lahey.com .
....and see if it does.
| |
| Phillip Helbig---remove CLOTHES to reply 2004-11-16, 3:57 pm |
| In article <cnb985$trc$1@online.de>, helbig@astro.multiCLOTHESvax.de
(Phillip Helbig---remove CLOTHES to reply) writes:
> In article <8v5md.340543$wV.212483@attbi_s54>, "James Van Buskirk"
> <not_valid@comcast.net> writes:
>
>
> I'll write one tomorrow...
>
>
> ....and see if it does.
Once I came up with a self-contained code, the problem went away. So I
conclude it is not a) a compiler problem nor b) a problem with my
understanding of the way Fortran works, but rather c) some problem with
(my use of) the NUMERICAL RECIPES code.
This code works:
--------------------------------------------------------------------
MODULE FOO_TEST
CONTAINS
FUNCTION FOO(FUNC,A,B)
IMPLICIT NONE
REAL, INTENT(IN) :: A, B
REAL :: FOO
INTERFACE
FUNCTION FUNC(X)
REAL, DIMENSION(:), INTENT(IN) :: X
REAL, DIMENSION(SIZE(X)) :: FUNC
END FUNCTION FUNC
END INTERFACE
FOO = 3*SUM(FUNC((/A,B/)))**2 + 2
END FUNCTION FOO
END MODULE FOO_TEST
MODULE Q_TEST
CONTAINS
FUNCTION Q(Z)
IMPLICIT NONE
REAL, DIMENSION(:), INTENT(IN) :: Z
REAL, DIMENSION(SIZE(Z)) :: Q
Q = 1.0/(1+Z)**3
END FUNCTION Q
END MODULE Q_TEST
PROGRAM TEST
USE FOO_TEST
USE Q_TEST
IMPLICIT NONE
REAL :: Y, A, B
READ*, A, B
Y = FOO(Q,A,B)
PRINT*, Y
END PROGRAM TEST
--------------------------------------------------------------------
while this code does not:
--------------------------------------------------------------------
MODULE Q_TEST
USE NRTYPE !!!!!!!
CONTAINS
FUNCTION Q(Z)
IMPLICIT NONE
REAL(SP), DIMENSION(:), INTENT(IN) :: Z !!!!!!!
REAL(SP), DIMENSION(SIZE(Z)) :: Q !!!!!!!
Q = 1.0/(1+Z)**3
END FUNCTION Q
END MODULE Q_TEST
PROGRAM TEST
USE Q_TEST
USE NRTYPE
USE NR, ONLY: QTRAP, QSIMP, QROMB
IMPLICIT NONE
REAL(SP) :: INTEGRAL, A, B
READ*, A, B
INTEGRAL = QTRAP(Q,A,B)
INTEGRAL = QSIMP(Q,A,B)
INTEGRAL = QROMB(Q,A,B)
END PROGRAM TEST
--------------------------------------------------------------------
Note that FUNCTION FOO is closely modeled on the NUMERICAL RECIPES
functions QTRAP, QSIMP and QROMB. The main difference is that in my
case FOO is contained within a module so the interface to it should be
automatic, while in the NUMERICAL RECIPES case the interface is in a
separate module from the function itself.
Perhaps if someone would post a sample of code using QTRAP, QSIMP or
QROMB which works, modeled as closely as possible on my code, then I can
find out where my problem lies.
| |
| Phillip Helbig---remove CLOTHES to reply 2004-11-16, 3:57 pm |
| In article <cncukg$h0s$1@online.de>, helbig@astro.multiCLOTHESvax.de
(Phillip Helbig---remove CLOTHES to reply) writes:
> In article <cnb985$trc$1@online.de>, helbig@astro.multiCLOTHESvax.de
> (Phillip Helbig---remove CLOTHES to reply) writes:
>
>
> Once I came up with a self-contained code, the problem went away. So I
> conclude it is not a) a compiler problem nor b) a problem with my
> understanding of the way Fortran works, but rather c) some problem with
> (my use of) the NUMERICAL RECIPES code.
None of the above. :-|
I've finally found the problem. Since compiling the NUMERICAL RECIPES
code, I had upgraded the Fortran compiler. After recompiling the
NUMERICAL RECIPES stuff, the problem went away. Thus, I was misled by
an inappropriate error message. I suppose the compiler should notice
that it is trying to USE stuff which was compiled with an older,
incompatible version of the compiler and issue a fatal error message in
that case, saying that one should recompile.
|
|
|
|
|