Home > Archive > Fortran > May 2005 > Troubles with some IMSL routines (eg EVLRG, and some other)
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 |
Troubles with some IMSL routines (eg EVLRG, and some other)
|
|
| Gojko Magazinovic 2005-05-26, 9:00 pm |
| Hi,
I tried to compile the following example program (copy/pasted from the
original Visual Numerics user's manual):
! Declare variables
USE IMSL
INTEGER LDA, N
PARAMETER (N=4, LDA=N)
REAL A(LDA,N)
COMPLEX EVAL(N)
EXTERNAL EVLRG, WRCRN
! Set values of A
! A = ( -2.0 2.0 2.0 2.0 )
! ( -3.0 3.0 2.0 2.0 )
! ( -2.0 0.0 4.0 2.0 )
! ( -1.0 0.0 0.0 5.0 )
DATA A/-2.0, -3.0, -2.0, -1.0, 2.0, 3.0, 0.0, 0.0, 2.0, 2.0, &
4.0, 0.0, 2.0, 2.0, 2.0, 5.0/
! Find eigenvalues of A
CALL EVLRG (N, A, LDA, EVAL)
! Print results
CALL WRCRN ('EVAL', 1, N, EVAL, 1, 0)
END
The following error messages appear:
--------------------Configuration: IMSL_Test - Win32
Debug--------------------
Compiling Fortran...
E:\Work\IMSL_Test\RealSvojstvene1.F90
E:\Work\IMSL_Test\RealSvojstvene1.F90(30) : Error: The attributes of
this name conflict with those made accessible by a USE statement.
[EVLRG]
CALL EVLRG (N, A, LDA, EVAL)
-----------^
E:\Work\IMSL_Test\RealSvojstvene1.F90(32) : Error: The attributes of
this name conflict with those made accessible by a USE statement.
[WRCRN]
CALL WRCRN ('EVAL', 1, N, EVAL, 1, 0)
-----------^
Error executing df.exe.
IMSL_Test.exe - 2 error(s), 0 warning(s)
Oh, yes, the system is CVF 6.6C Pro under PC Win2000. The IMSL library
is a part of a system. I contacted Visual Numerics but to date nobody
replied.
Have you any suggestion to resolve the problem? Thanks in advance.
Gojko Magazinovic
---------------------------------------------------------
CADEA d.o.o. E-mail:
Split, Croatia gmag AT cadea DOT hr
| |
| Dave Seaman 2005-05-26, 9:00 pm |
| On Thu, 26 May 2005 22:10:49 +0100, Gojko Magazinovic wrote:
> Hi,
> I tried to compile the following example program (copy/pasted from the
> original Visual Numerics user's manual):
> ! Declare variables
> USE IMSL
> INTEGER LDA, N
> PARAMETER (N=4, LDA=N)
> REAL A(LDA,N)
> COMPLEX EVAL(N)
> EXTERNAL EVLRG, WRCRN
> ! Set values of A
> ! A = ( -2.0 2.0 2.0 2.0 )
> ! ( -3.0 3.0 2.0 2.0 )
> ! ( -2.0 0.0 4.0 2.0 )
> ! ( -1.0 0.0 0.0 5.0 )
> DATA A/-2.0, -3.0, -2.0, -1.0, 2.0, 3.0, 0.0, 0.0, 2.0, 2.0, &
> 4.0, 0.0, 2.0, 2.0, 2.0, 5.0/
> ! Find eigenvalues of A
> CALL EVLRG (N, A, LDA, EVAL)
> ! Print results
> CALL WRCRN ('EVAL', 1, N, EVAL, 1, 0)
> END
> The following error messages appear:
> --------------------Configuration: IMSL_Test - Win32
> Debug--------------------
> Compiling Fortran...
> E:\Work\IMSL_Test\RealSvojstvene1.F90
> E:\Work\IMSL_Test\RealSvojstvene1.F90(30) : Error: The attributes of
> this name conflict with those made accessible by a USE statement.
> [EVLRG]
> CALL EVLRG (N, A, LDA, EVAL)
> -----------^
> E:\Work\IMSL_Test\RealSvojstvene1.F90(32) : Error: The attributes of
> this name conflict with those made accessible by a USE statement.
> [WRCRN]
> CALL WRCRN ('EVAL', 1, N, EVAL, 1, 0)
> -----------^
> Error executing df.exe.
> IMSL_Test.exe - 2 error(s), 0 warning(s)
> Oh, yes, the system is CVF 6.6C Pro under PC Win2000. The IMSL library
> is a part of a system. I contacted Visual Numerics but to date nobody
> replied.
> Have you any suggestion to resolve the problem? Thanks in advance.
You should remove the EXTERNAL EVLRG, WRCRN declaration. It conflicts with the
USE IMSL statement, and host association is preferable because it gives the
compiler an opportunity to check argument compatibility.
--
Dave Seaman
Judge Yohn's mistakes revealed in Mumia Abu-Jamal ruling.
<http://www.commoncouragepress.com/i...book&bookid=228>
| |
| Gojko Magazinovic 2005-05-26, 9:00 pm |
| On Thu, 26 May 2005 20:36:28 +0000 (UTC), Dave Seaman
<dseaman@no.such.host> wrote:
>You should remove the EXTERNAL EVLRG, WRCRN declaration. It conflicts with the
>USE IMSL statement, and host association is preferable because it gives the
>compiler an opportunity to check argument compatibility.
Thank you. It works for EVLRG, but WRCRN persists:
Compiling Fortran...
E:\Work\IMSL_Test\RealSvojstvene1.F90
E:\Work\IMSL_Test\RealSvojstvene1.F90(32) : Error: If the actual
argument is scalar, the corresponding dummy argument shall be scalar
unless the actual argument is an element of an array that is not an
assumed-shape or pointer array, or a substring
of such an element. [TITLE]
CALL WRCRN ('EVAL', 1, N, EVAL, 1, 0)
-----------^
Error executing df.exe.
IMSL_Test.exe - 1 error(s), 0 warning(s)
Any other suggestions?
Gojko Magazinovic
---------------------------------------------------------
CADEA d.o.o. E-mail:
Split, Croatia gmag AT cadea DOT hr
| |
| Dave Seaman 2005-05-26, 9:00 pm |
| On Thu, 26 May 2005 23:26:01 +0100, Gojko Magazinovic wrote:
> On Thu, 26 May 2005 20:36:28 +0000 (UTC), Dave Seaman
><dseaman@no.such.host> wrote:
[color=darkred]
> Thank you. It works for EVLRG, but WRCRN persists:
> Compiling Fortran...
> E:\Work\IMSL_Test\RealSvojstvene1.F90
> E:\Work\IMSL_Test\RealSvojstvene1.F90(32) : Error: If the actual
> argument is scalar, the corresponding dummy argument shall be scalar
> unless the actual argument is an element of an array that is not an
> assumed-shape or pointer array, or a substring
> of such an element. [TITLE]
> CALL WRCRN ('EVAL', 1, N, EVAL, 1, 0)
> -----------^
> Error executing df.exe.
> IMSL_Test.exe - 1 error(s), 0 warning(s)
> Any other suggestions?
The easy way would be to drop the USE IMSL and put back the EXTERNAL
declarations, which would cause the compiler to be less stringent in its
argument checking.
But if you prefer to get the Fortran 90 interface right, you should be
able to use the USE IMSL specification with a call that looks something
like the following:
CALL WRCRN( 'EVAL', EVAL(1:N) )
or if EVAL is correctly dimensioned, you can even shorten that to
CALL WRCRN( 'EVAL', EVAL )
This makes use of optional arguments that are available when you use the
Fortran 90 interface:
NRA number of rows (default = size(EVAL,1))
NCA number of columns (default = size(EVAL,2))
LDA leading dimension of EVAL (default = size(EVAL,1))
ITRING triangle option (default = 0)
If you want to specify a nondefault value for one of these arguments, you
can do so using keyword form:
CALL WRCRN( 'EVAL', EVAL, NCA=N )
--
Dave Seaman
Judge Yohn's mistakes revealed in Mumia Abu-Jamal ruling.
<http://www.commoncouragepress.com/i...book&bookid=228>
| |
| Gojko Magazinovic 2005-05-26, 9:00 pm |
| On Thu, 26 May 2005 21:48:52 +0000 (UTC), Dave Seaman
<dseaman@no.such.host> wrote:
>The easy way would be to drop the USE IMSL and put back the EXTERNAL
>declarations, which would cause the compiler to be less stringent in its
>argument checking.
>
>But if you prefer to get the Fortran 90 interface right, you should be
>able to use the USE IMSL specification with a call that looks something
>like the following:
>
> CALL WRCRN( 'EVAL', EVAL(1:N) )
>
>or if EVAL is correctly dimensioned, you can even shorten that to
>
> CALL WRCRN( 'EVAL', EVAL )
>
>This makes use of optional arguments that are available when you use the
>Fortran 90 interface:
>
> NRA number of rows (default = size(EVAL,1))
> NCA number of columns (default = size(EVAL,2))
> LDA leading dimension of EVAL (default = size(EVAL,1))
> ITRING triangle option (default = 0)
>
>If you want to specify a nondefault value for one of these arguments, you
>can do so using keyword form:
>
> CALL WRCRN( 'EVAL', EVAL, NCA=N )
Thank you very much for a kind cooperation. Unfortunately, neither
suggestions resolved the problem on my system:
a) If I drop the USE IMSL, a lot of "unresolved external symbol"
errors appear
b) If I use CALL WRCRN( 'EVAL', EVAL ), the following appears:
Compiling Fortran...
E:\Work\IMSL_Test\RealSvojstvene1.F90
E:\Work\IMSL_Test\RealSvojstvene1.F90(32) : Error: The type of the
actual argument differs from the type of the dummy argument. [EVAL]
CALL WRCRN ('EVAL', EVAL)
--------------------------^
E:\Work\IMSL_Test\RealSvojstvene1.F90(32) : Error: A non-optional
actual argument must be present when invoking a procedure with an
explicit interface. [NCA]
CALL WRCRN ('EVAL', EVAL)
-----------^
E:\Work\IMSL_Test\RealSvojstvene1.F90(32) : Error: A non-optional
actual argument must be present when invoking a procedure with an
explicit interface. [A]
CALL WRCRN ('EVAL', EVAL)
-----------^
E:\Work\IMSL_Test\RealSvojstvene1.F90(32) : Error: A non-optional
actual argument must be present when invoking a procedure with an
explicit interface. [LDA]
CALL WRCRN ('EVAL', EVAL)
-----------^
E:\Work\IMSL_Test\RealSvojstvene1.F90(32) : Error: A non-optional
actual argument must be present when invoking a procedure with an
explicit interface. [ITRING]
CALL WRCRN ('EVAL', EVAL)
-----------^
E:\Work\IMSL_Test\RealSvojstvene1.F90(32) : Error: If the actual
argument is scalar, the corresponding dummy argument shall be scalar
unless the actual argument is an element of an array that is not an
assumed-shape or pointer array, or a substring
of such an element. [TITLE]
CALL WRCRN ('EVAL', EVAL)
-----------^
E:\Work\IMSL_Test\RealSvojstvene1.F90(32) : Error: The shape matching
rules of actual arguments and dummy arguments have been violated.
[EVAL]
CALL WRCRN ('EVAL', EVAL)
--------------------------^
Error executing df.exe.
IMSL_Test.exe - 7 error(s), 0 warning(s)
What I am doing wrong?
Gojko Magazinovic
---------------------------------------------------------
CADEA d.o.o. E-mail:
Split, Croatia gmag AT cadea DOT hr
| |
| James Van Buskirk 2005-05-27, 4:01 am |
| "Gojko Magazinovic" <gmag@cadea.hr> wrote in message
news:vmic9156ihkbmbtirpurrjk6e7o7u8ok5e@
4ax.com...
> CALL WRCRN ('EVAL', 1, N, EVAL, 1, 0)
This just looks like a compiler bug. The error statement
refers to the TITLE argument, but your TITLE argument, 'EVAL' ,
is just fine and consistent with the IMSL documentation on
http://gams.nist.gov . Reading the error message carefully,
I was able to find a syntax that CVF likes:
CALL WRCRN ((/'EVAL'/), 1, N, EVAL, 1, 0)
Hope this helps.
--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end
| |
| Boo, hoo! 2005-05-27, 4:01 am |
|
"Gojko Magazinovic" <gmag@cadea.hr> wrote in message
news:6sdc91121mse42v31kfqepibifm6a9i8h7@
4ax.com...
Here you go:
:
use imslf90
use linear_operators
use dfport
:
!Use IMSLF90 to get the eigenvalues of A
de = EIG(a)
:
--
You're Welcome,
Gerry T.
______
"Facts are meaningless. You could use facts to prove anything that's even
remotely true." -- Homer Simpson.
| |
| Dave Seaman 2005-05-27, 4:01 am |
| On Fri, 27 May 2005 00:35:49 +0100, Gojko Magazinovic wrote:
> On Thu, 26 May 2005 21:48:52 +0000 (UTC), Dave Seaman
><dseaman@no.such.host> wrote:
[color=darkred]
> Thank you very much for a kind cooperation. Unfortunately, neither
> suggestions resolved the problem on my system:
> a) If I drop the USE IMSL, a lot of "unresolved external symbol"
> errors appear
That makes me suspect that you have not specified the proper libraries for
linking. I can't help you with that, because it's platform-dependent and I
don't use Windows.
> b) If I use CALL WRCRN( 'EVAL', EVAL ), the following appears:
> Compiling Fortran...
> E:\Work\IMSL_Test\RealSvojstvene1.F90
> E:\Work\IMSL_Test\RealSvojstvene1.F90(32) : Error: The type of the
> actual argument differs from the type of the dummy argument. [EVAL]
> CALL WRCRN ('EVAL', EVAL)
> --------------------------^
The second argument (called "A" in the documentation) is supposed to be a
complex NRAxNCA matrix. What type is EVAL?
> E:\Work\IMSL_Test\RealSvojstvene1.F90(32) : Error: A non-optional
> actual argument must be present when invoking a procedure with an
> explicit interface. [NCA]
> CALL WRCRN ('EVAL', EVAL)
> -----------^
That message looks wrong. According to the documentation, there are two
non-optional actual arguments (TITLE and A) already present in that call, and
NCA is indeed an optional argument.
By the way, the documentation says you should USE WRCRN_INT in order to be able
to call this subroutine with the F90 interface. Perhaps that is included in
your USE IMSL interface, but I have not seen that interface mentioned on other
platforms where I have used IMSL and therefore it looks like a Windows-specific
thing. The fact that you are seeing an error message that doesn't match the
documentation suggests that you might try using the interface that is described
in the IMSL documentation instead of USE IMSL. You would do the same for each
IMSL routine you call (if you call FOO, then you need to USE FOO_INT).
> E:\Work\IMSL_Test\RealSvojstvene1.F90(32) : Error: A non-optional
> actual argument must be present when invoking a procedure with an
> explicit interface. [A]
> CALL WRCRN ('EVAL', EVAL)
> -----------^
A is indeed present in that call. It's the second argument.
> What I am doing wrong?
I don't know. You have some suggestions from others that may be helpful.
--
Dave Seaman
Judge Yohn's mistakes revealed in Mumia Abu-Jamal ruling.
<http://www.commoncouragepress.com/i...book&bookid=228>
| |
| Gojko Magazinovic 2005-05-27, 8:57 am |
| On Thu, 26 May 2005 19:43:03 -0600, "James Van Buskirk"
<not_valid@comcast.net> wrote:
>"Gojko Magazinovic" <gmag@cadea.hr> wrote in message
> news:vmic9156ihkbmbtirpurrjk6e7o7u8ok5e@
4ax.com...
>
>
>This just looks like a compiler bug. The error statement
>refers to the TITLE argument, but your TITLE argument, 'EVAL' ,
>is just fine and consistent with the IMSL documentation on
>http://gams.nist.gov . Reading the error message carefully,
>I was able to find a syntax that CVF likes:
>
> CALL WRCRN ((/'EVAL'/), 1, N, EVAL, 1, 0)
>
>Hope this helps.
This works fine. Many thanks to all involved.
Gojko Magazinovic
---------------------------------------------------------
CADEA d.o.o. E-mail:
Split, Croatia gmag AT cadea DOT hr
| |
| Steve Lionel 2005-05-27, 4:01 pm |
| On Fri, 27 May 2005 09:09:23 +0100, Gojko Magazinovic <gmag@cadea.hr> wrote:
[color=darkred]
>On Thu, 26 May 2005 19:43:03 -0600, "James Van Buskirk"
><not_valid@comcast.net> wrote:
>
It's not a compiler bug, but rather a bug in the IMSL declarations. VNI had
described all character string arguments as:
character, dimension(*) :: title
rather than
character(*) :: title
In older versions of CVF, this worked, but when we fixed the compiler in CVF
6.6B to diagnose the error of passing a scalar to an array argument, then it
stopped working. James' suggestion is a fine workaround.
I convinced VNI to correct this for the newer version of IMSL included in
Intel Visual Fortran Professional Edition. The program builds fine with Intel
Visual Fortran, once I make the minor source edits required by IMSL 5.0
(replace USE IMSL with USE NUMERICAL_LIBRARIES and add an INCLUDE line to
bring in the appropriate library directives (or specify the libraries
explicitly).
Steve Lionel
Software Products Division
Intel Corporation
Nashua, NH
User communities for Intel Software Development Products
http://softwareforums.intel.com/
Intel Fortran Support
http://developer.intel.com/software/products/support/
| |
| James Van Buskirk 2005-05-27, 4:01 pm |
| "Steve Lionel" <Steve.Lionel@REMOVEintelME.com> wrote in message
news:5g7e911o6e6246umqhi4r5t8e0jc8cs4et@
4ax.com...
> It's not a compiler bug, but rather a bug in the IMSL declarations. VNI
had
> described all character string arguments as:
> character, dimension(*) :: title
> rather than
> character(*) :: title
Oog. This possibility didn't occur to me because there
would be no way for the calling program to communicate the
length of the TITLE string. Did VNI write WRCRN in some
other language like F77 or C and then just make up
INTERFACE blocks for the F90 version?
--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end
| |
| Steve Lionel 2005-05-27, 4:01 pm |
| On Fri, 27 May 2005 09:59:30 -0600, "James Van Buskirk"
<not_valid@comcast.net> wrote:
>"Steve Lionel" <Steve.Lionel@REMOVEintelME.com> wrote in message
> news:5g7e911o6e6246umqhi4r5t8e0jc8cs4et@
4ax.com...
>
>had
>
>
>
>
>Oog. This possibility didn't occur to me because there
>would be no way for the calling program to communicate the
>length of the TITLE string. Did VNI write WRCRN in some
>other language like F77 or C and then just make up
>INTERFACE blocks for the F90 version?
Yes, WRCRN (and all of IMSL in that version) was written in F77 (as far as I
know) and they made up interface blocks for F90 users.
Prior to CVF 6.6B, the compiler would let you pass a scalar to an array, and
since the bounds information isn't passed, it would just take the string
length of the argument and it would work.
In IMSL Fortran Library 5.0, included with IVF Pro, there is a new set of
modules, one per routine class, that provide generic interfaces. There's also
a LOT of real F95 code in the library. The old NUMERICAL_LIBRARIES (module
IMSL was just a USE of that) was just explicit interfaces to the F77-style
routines. Now you have optional arguments and generics. The downside is that
you may need to add several USE lines to your code, because of the way they
broke it out. (For example, USE WRCRN_INT). The old NUMERICAL_LIBRARIES
module is still there. (But there is not a module IMSL anymore - that's easy
to deal with if necessary.) The documentation tells you the module name to
use, but after a while, you can figure it out on your own.
I suppose while I'm here, I'll point out that, unlike for CVF Pro, you get
technical support (from Intel) on IMSL if you buy IVF Pro.
Steve Lionel
Software Products Division
Intel Corporation
Nashua, NH
User communities for Intel Software Development Products
http://softwareforums.intel.com/
Intel Fortran Support
http://developer.intel.com/software/products/support/
| |
| James Van Buskirk 2005-05-27, 8:57 pm |
| "Steve Lionel" <Steve.Lionel@REMOVEintelME.com> wrote in message
news:gbne91dj3mt69ap88jo73q9aubklkv905f@
4ax.com...
> Yes, WRCRN (and all of IMSL in that version) was written in F77 (as far as
I
> know) and they made up interface blocks for F90 users.
> Prior to CVF 6.6B, the compiler would let you pass a scalar to an array,
and
> since the bounds information isn't passed, it would just take the string
> length of the argument and it would work.
Thanks for the explanation. This is one of the things us F90 types
fret about when we see a recommendation to use interface blocks
instead of module procedures to provide an explicit interface: the
exlicit interface might end up not agreeing with the interface of
the actual procedure.
BTW, you pointed out a mistake in one of my examples this w in
email, and I thought your explanation was so detailed and informative
that the group might benefit from it, but I couldn't post it myself
because it was your message, after all. Could you be so kind as to
append your excellent email message to the thread in question?
--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end
| |
| Boo, hoo! 2005-05-28, 3:58 am |
|
"Steve Lionel" <Steve.Lionel@REMOVEintelME.com> Fortran's own Zeilig wanabe
wrote in message news:gbne91dj3mt69ap88jo73q9aubklkv905f@
4ax.com...
> I suppose while I'm here, I'll point out that, unlike for CVF Pro, you
get
> technical support (from Intel) on IMSL if you buy IVF Pro.
What arrogant corporate wa wa!
Given IMSL's open source pedigree, however disguised in F95 sheep's
clothing a la IVF Pro, only the greatest of dullards require tech support
from Intel on its usage.
With CVF Pro, the 'Gold Standard' in F95 as Mr Lionel well recalls, IMSL,
in its entirety if need be, can be painstakingly repackaged as a tlb in
compliance with the EULA and is freely distributable, VNI be damned. Not so
with the pseudo DLL version of IMSL that comes with IVF Pro. Hence the
dilatory switch from static to dynamic linking of IMSL as now promoted by
wa wa Lionel. Plus, annual subscription to IVF Pro is scaled by a factor of
2.5 relative to IVF Std in order to avail of the latest cosmetic (sic
F95-abetted simulacra) changes to IMSL. Throughout the tenure of D/CVF Pro,
the only change to IMSL was versioning and a recompile, but at least it was
free. Not so with IVF Pro, where governance takes a back seat to selling
chips, wa wa Lionel's current reason d'rat.
--
--
You're Welcome,
Gerry T.
______
"The most successful tyranny is not the one that uses force to assure
uniformity but the one that removes the awareness of other possibilities,
that makes it seem inconceivable that other ways are viable, that removes
the sense that there is an outside." -- Allan Bloom, in The Closing of the
American Mind.
| |
| Steve Lionel 2005-05-31, 4:01 pm |
| On Fri, 27 May 2005 12:37:03 -0600, "James Van Buskirk"
<not_valid@comcast.net> wrote:
>BTW, you pointed out a mistake in one of my examples this w in
>email, and I thought your explanation was so detailed and informative
>that the group might benefit from it, but I couldn't post it myself
>because it was your message, after all. Could you be so kind as to
>append your excellent email message to the thread in question?
Will do.
Steve Lionel
Software Products Division
Intel Corporation
Nashua, NH
User communities for Intel Software Development Products
http://softwareforums.intel.com/
Intel Fortran Support
http://developer.intel.com/software/products/support/
|
|
|
|
|