Home > Archive > Fortran > March 2006 > How can I use dreal and dimag in a f90 program?
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 |
How can I use dreal and dimag in a f90 program?
|
|
|
| Hello
I know it is a silly question but I confess that I don't know what to
do. I converted my old f77 program to a free format f90. The f77 code
was compiled by ifort (intel) - no complains on dreal and dimag - and
runs fine. When I tried ifort with the f90 version, ifort issues a
complaint and en error during the link process.
ifort -nbs -g -debug all -c Bispec.f90
fortcom: Warning: Bispec.f90, line 1282: This argument's data type is
incompatible with this intrinsic procedure; procedure assumed EXTERNAL.
[DREAL]
sp (jk) = sp (jk) + dreal (f (k) / cs2 * f (lb - k) )
---------------------------------------^
fortcom: Warning: Bispec.f90, line 1298: This argument's data type is
incompatible with this intrinsic procedure; procedure assumed EXTERNAL.
[DIMAG]
bi (nb) = bi (nb) + dimag (f (il) / cs3 * f (il) * f (lb - 2 * il) )
----------------------------------------------------^
ifort -Vaxlib -o Bispec f2kcli.o numread.o rnumread.o charead.o
readhead.o cdchi.o cdg.o number.o sort.o head.o far.o dcholdc.o
dcholsl.o dinverse.o dfft.o outar.o taper.o p2chi.o zroots.o port.o
stats.o Bispec.o -lmatio -lz
/usr/lib/libmatio.a(mat.o)(.text+0x333): In function `Mat_VarDelete':
/home/eduardo/Hinich_2006/matio/src/mat.c:476: warning: the use of
`mktemp' is dangerous, better use `mkstemp'
Bispec.o(.text+0xb1ce): In function `p23':
/home/eduardo/Hinich_2006/bispec_f90/Bispec.f90:1282: undefined
reference to `dreal_'
Bispec.o(.text+0xb3f8):Bispec.f90:1297: undefined reference to `dreal_'
Bispec.o(.text+0xb58f):Bispec.f90:1298: undefined reference to `dimag_'
Bispec.o(.text+0xb7d7):Bispec.f90:1314: undefined reference to `dreal_'
Bispec.o(.text+0xb95e):Bispec.f90:1316: undefined reference to `dimag_'
Bispec.o(.text+0xbb8f):Bispec.f90:1330: undefined reference to `dreal_'
Bispec.o(.text+0xbd1c):Bispec.f90:1332: undefined reference to `dimag_'
Bispec.o(.text+0xbf3d):Bispec.f90:1346: undefined reference to `dreal_'
Bispec.o(.text+0xc0c8):Bispec.f90:1348: undefined reference to `dimag_'
make: *** [Bispec] Error 1
What am I missing?
Ed
| |
| meek@skyway.usask.ca 2006-02-01, 9:59 pm |
| In a previous article, "Ed" <emammendes@gmail.com> wrote:
>Hello
>
>I know it is a silly question but I confess that I don't know what to
>do. I converted my old f77 program to a free format f90. The f77 code
>was compiled by ifort (intel) - no complains on dreal and dimag - and
>runs fine. When I tried ifort with the f90 version, ifort issues a
>complaint and en error during the link process.
>
>ifort -nbs -g -debug all -c Bispec.f90
>fortcom: Warning: Bispec.f90, line 1282: This argument's data type is
>incompatible with this intrinsic procedure; procedure assumed EXTERNAL.
> [DREAL]
>sp (jk) = sp (jk) + dreal (f (k) / cs2 * f (lb - k) )
Is f defined as double precision? It should be.
It may also be necessary to make cs2 DP ... but usually
the compiler will convert automatically to the highest
precision previously used in calculating the expression.
Chris
<snip rest>
| |
| Richard E Maine 2006-02-01, 9:59 pm |
| <m @skyway.usask.ca> wrote:
> It may also be necessary to make cs2 DP ... but usually
> the compiler will convert automatically to the highest
> precision previously used in calculating the expression.
"Usually" in this case means "always, as required by the standard."
Except that there is no bit about "highest expression previously used."
Instead, it is the highest precision of the operands to a particular
operation (and this then recursively applies to operations that have
this result as an operand). For example, in
x = (double/double) + (single/single)
the single/single gives a single result. Th efact that there was a
"previously used" double is irrelevant because it is not an operand in
the single/single operation.
P.S. Yes, I know that the standard guarantees only the kind of the
result rather than the accuracy of the value, but I consider that point
moot, as changing the kind of the operands doesn't guarantee anything
any better either.
--
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
| |
| meek@skyway.usask.ca 2006-02-01, 9:59 pm |
| In a previous article, nospam@see.signature (Richard E Maine) wrote:
><m@skyway.usask.ca> wrote:
>
>
>"Usually" in this case means "always, as required by the standard."
>
>Except that there is no bit about "highest expression previously used."
>Instead, it is the highest precision of the operands to a particular
>operation (and this then recursively applies to operations that have
>this result as an operand). For example, in
>
> x = (double/double) + (single/single)
>
>the single/single gives a single result. Th efact that there was a
>"previously used" double is irrelevant because it is not an operand in
>the single/single operation.
>
>P.S. Yes, I know that the standard guarantees only the kind of the
>result rather than the accuracy of the value, but I consider that point
>moot, as changing the kind of the operands doesn't guarantee anything
>any better either.
>
>--
>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
Yes - I thought that would get a correction of some sort...
but the original comment should have been enough to help
the OP.
I definitely would not base any program on this aspect of
the standard without testing it !
(or maybe I would if compiler manufacturer offered $1M
to anyone and everyone tripping over any departure from the std.!)
Chris
| |
| Richard E Maine 2006-02-01, 9:59 pm |
| <m@skyway.usask.ca> wrote:
> I definitely would not base any program on this aspect of
> the standard without testing it !
Be conservative on that if you like. I have never, in my 35+ years of
Fortran programming seen a compiler get this one (mixed-precision
operations) wrong. Admitedly, I didn't start with Fortran until 1968,
and my experience with pre-f66 compilers is limitted. This is an awfully
basic rule and has been in every version of the standard including f66.
There are plenty of other things I've seen compilers get wrong, but not
this one. I'll concentrate my testing efforts on things where my
experience gives me more ground for suspicion.
--
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
| |
| James Van Buskirk 2006-02-01, 9:59 pm |
| "Richard E Maine" <nospam@see.signature> wrote in message
news:1ha301v.19e9uyr1ppwxtxN%nospam@see.signature...
> Be conservative on that if you like. I have never, in my 35+ years of
> Fortran programming seen a compiler get this one (mixed-precision
> operations) wrong.
Actually, the first Windows version of g95 had a bug with
mixed-precision operations. Of course, this was over a year ago
and g95 has come a (quite remarkably) long way since then.
And where different LOGICAL kinds are concerned, I have
noticed a rather higher error rate. Look at the g95 blog
or gfortran bugzilla.
--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end
| |
|
| Ed wrote in message <1138798954.228115.207630@g14g2000cwa.googlegroups.com>...
>Hello
>
>I know it is a silly question but I confess that I don't know what to
>do. I converted my old f77 program to a free format f90. The f77 code
>was compiled by ifort (intel) - no complains on dreal and dimag - and
>runs fine. When I tried ifort with the f90 version, ifort issues a
>complaint and en error during the link process.
>
>ifort -nbs -g -debug all -c Bispec.f90
>fortcom: Warning: Bispec.f90, line 1282: This argument's data type is
>incompatible with this intrinsic procedure; procedure assumed EXTERNAL.
> [DREAL]
>sp (jk) = sp (jk) + dreal (f (k) / cs2 * f (lb - k) )
>---------------------------------------^
>fortcom: Warning: Bispec.f90, line 1298: This argument's data type is
>incompatible with this intrinsic procedure; procedure assumed EXTERNAL.
> [DIMAG]
> bi (nb) = bi (nb) + dimag (f (il) / cs3 * f (il) * f (lb - 2 * il) )
>----------------------------------------------------^
>ifort -Vaxlib -o Bispec f2kcli.o numread.o rnumread.o charead.o
>readhead.o cdchi.o cdg.o number.o sort.o head.o far.o dcholdc.o
>dcholsl.o dinverse.o dfft.o outar.o taper.o p2chi.o zroots.o port.o
>stats.o Bispec.o -lmatio -lz
>/usr/lib/libmatio.a(mat.o)(.text+0x333): In function `Mat_VarDelete':
>/home/eduardo/Hinich_2006/matio/src/mat.c:476: warning: the use of
>`mktemp' is dangerous, better use `mkstemp'
>Bispec.o(.text+0xb1ce): In function `p23':
>/home/eduardo/Hinich_2006/bispec_f90/Bispec.f90:1282: undefined
>reference to `dreal_'
>Bispec.o(.text+0xb3f8):Bispec.f90:1297: undefined reference to `dreal_'
>Bispec.o(.text+0xb58f):Bispec.f90:1298: undefined reference to `dimag_'
>Bispec.o(.text+0xb7d7):Bispec.f90:1314: undefined reference to `dreal_'
>Bispec.o(.text+0xb95e):Bispec.f90:1316: undefined reference to `dimag_'
>Bispec.o(.text+0xbb8f):Bispec.f90:1330: undefined reference to `dreal_'
>Bispec.o(.text+0xbd1c):Bispec.f90:1332: undefined reference to `dimag_'
>Bispec.o(.text+0xbf3d):Bispec.f90:1346: undefined reference to `dreal_'
>Bispec.o(.text+0xc0c8):Bispec.f90:1348: undefined reference to `dimag_'
>make: *** [Bispec] Error 1
>
>What am I missing?
Use the generic procedure names REAL and AIMAG.
Note that with REAL, you MUST use the KIND= specifier.
| |
|
| m@skyway.usask.ca wrote in message <1FEB06.13142009@skyway.usask.ca>...
>In a previous article, "Ed" <emammendes@gmail.com> wrote:
>
> Is f defined as double precision? It should be.
> It may also be necessary to make cs2 DP ... but usually
>the compiler will convert automatically to the highest
>precision previously used in calculating the expression.
Not in the case of REAL, where KIND MUST be specified.
| |
| James Van Buskirk 2006-02-01, 9:59 pm |
| "robin" <robin_v@bigpond.com> wrote in message
news:sacEf.233322$V7.4305@news-server.bigpond.net.au...
> Use the generic procedure names REAL and AIMAG.
Wrong answer: the problem lay in his declarations of
complex variables.
> Note that with REAL, you MUST use the KIND= specifier.
Also wrong: it's the CMPLX intrinsic that needs the KIND=
specifier (unless you want the output to be default complex).
--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end
| |
| Dan Nagle 2006-02-01, 9:59 pm |
| Hello,
robin wrote:
> Ed wrote in message <1138798954.228115.207630@g14g2000cwa.googlegroups.com>...
<snip>
>
>
> Use the generic procedure names REAL and AIMAG.
> Note that with REAL, you MUST use the KIND= specifier.
If a kind specifier is not used in the real intrinsic,
the result is default kind. Kind must be specified
only if you want a non-default result. Same goes for aimag.
--
Cheers!
Dan Nagle
Purple Sage Computing Solutions, Inc.
| |
| Rich Townsend 2006-02-02, 3:57 am |
| Dan Nagle wrote:
> Hello,
>
> robin wrote:
>
>
>
> <snip>
>
>
>
> If a kind specifier is not used in the real intrinsic,
> the result is default kind. Kind must be specified
> only if you want a non-default result. Same goes for aimag.
>
Hmmm, I thought that only applied to COMPLEX(). That is, REAL(0.D0) is double
precision, but COMPLEX(0.D0) is single (default) precision. Are you sure?
cheers,
Rich
| |
| Richard Maine 2006-02-02, 3:57 am |
| Rich Townsend <rhdt@barVOIDtol.udel.edu> wrote:
> Dan Nagle wrote:
>
> Hmmm, I thought that only applied to COMPLEX(). That is, REAL(0.D0) is double
> precision, but COMPLEX(0.D0) is single (default) precision. Are you sure?
Dan's mostly right here. Real(0.d0) is single, as he said. However,
there is a case where real without a kind isn't default. real(complex)
gives the same kind as the complex.
Without a kind parameter, you get default kind, except for the case of
Real(complex), which is just an "extract the real part" function, where
it seems "obvious" that you would normally want the real part to be the
same kind as the complex was. I consider this mostly "obvious".
Cmplx is the odd case, just because of the historical oddity of there
being no double complex prior to f90. And note it is cmplx. There is no
complex intrinsic in standard Fortran (though I have sympathy for the
suggestion of making one that fixes the "oddity" of cmplx).
--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
| |
| Rich Townsend 2006-02-02, 3:57 am |
| Richard Maine wrote:
> Rich Townsend <rhdt@barVOIDtol.udel.edu> wrote:
>
>
>
>
>
>
> Dan's mostly right here. Real(0.d0) is single, as he said. However,
> there is a case where real without a kind isn't default. real(complex)
> gives the same kind as the complex.
>
> Without a kind parameter, you get default kind, except for the case of
> Real(complex), which is just an "extract the real part" function, where
> it seems "obvious" that you would normally want the real part to be the
> same kind as the complex was. I consider this mostly "obvious".
>
> Cmplx is the odd case, just because of the historical oddity of there
> being no double complex prior to f90. And note it is cmplx. There is no
> complex intrinsic in standard Fortran (though I have sympathy for the
> suggestion of making one that fixes the "oddity" of cmplx).
>
OK, thanks -- yes, it was the REAL(complex) I was probably thinking about as
preserving KIND. And yep, CMPLX, not COMPLEX.
cheers,
Rich
| |
| Dan Nagle 2006-02-02, 7:58 am |
| Hello,
Rich Townsend wrote:
<snip>
> Hmmm, I thought that only applied to COMPLEX(). That is, REAL(0.D0) is
> double precision, but COMPLEX(0.D0) is single (default) precision. Are
> you sure?
>
> cheers,
>
> Rich
You're right. When used for _conversion_, you get default kind.
When used to extract the real part of a complex (which you might
consider to be conversion or not) you get the kind of the argument.
Yes, we went through this before. :-(
--
Cheers!
Dan Nagle
Purple Sage Computing Solutions, Inc.
| |
|
| Ed wrote in message <1138798954.228115.207630@g14g2000cwa.googlegroups.com>...
>I know it is a silly question but I confess that I don't know what to
>do. I converted my old f77 program to a free format f90. The f77 code
>was compiled by ifort (intel) - no complains on dreal and dimag - and
>runs fine. When I tried ifort with the f90 version, ifort issues a
>complaint and en error during the link process.
>
>fortcom: Warning: Bispec.f90, line 1282: This argument's data type is
>incompatible with this intrinsic procedure; procedure assumed EXTERNAL.
> [DREAL]
>sp (jk) = sp (jk) + dreal (f (k) / cs2 * f (lb - k) )
>---------------------------------------^
>fortcom: Warning: Bispec.f90, line 1298: This argument's data type is
>incompatible with this intrinsic procedure; procedure assumed EXTERNAL.
> [DIMAG]
> bi (nb) = bi (nb) + dimag (f (il) / cs3 * f (il) * f (lb - 2 * il) )
>----------------------------------------------------^
>/home/eduardo/Hinich_2006/bispec_f90/Bispec.f90:1282: undefined
>reference to `dreal_'
>Bispec.o(.text+0xb3f8):Bispec.f90:1297: undefined reference to `dreal_'
>Bispec.o(.text+0xb58f):Bispec.f90:1298: undefined reference to `dimag_'
>Bispec.o(.text+0xb7d7):Bispec.f90:1314: undefined reference to `dreal_'
>Bispec.o(.text+0xb95e):Bispec.f90:1316: undefined reference to `dimag_'
>Bispec.o(.text+0xbb8f):Bispec.f90:1330: undefined reference to `dreal_'
>Bispec.o(.text+0xbd1c):Bispec.f90:1332: undefined reference to `dimag_'
>Bispec.o(.text+0xbf3d):Bispec.f90:1346: undefined reference to `dreal_'
>Bispec.o(.text+0xc0c8):Bispec.f90:1348: undefined reference to `dimag_'
>make: *** [Bispec] Error 1
>
>What am I missing?
The appropriate way is to use REAL with the KIND specified, etc.
| |
| Rich Townsend 2006-03-22, 4:01 am |
| robin wrote:
> Ed wrote in message <1138798954.228115.207630@g14g2000cwa.googlegroups.com>...
>
>
>
>
> The appropriate way is to use REAL with the KIND specified, etc.
>
>
The same advice as given a month and a half ago. But still no working
demonstration of TRIM() in F77.
cheers,
Rich
| |
|
| Rich Townsend wrote in message ...
>robin wrote:
[color=darkred]
>The same advice as given a month and a half ago.
Obviously sound advice. :)
Apparently a glitch in my newsreader, which showed up the postings as new
messages.
BTW, did you have nothing better to do ?
| |
| Rich Townsend 2006-03-23, 7:04 pm |
| robin wrote:
> Rich Townsend wrote in message ...
>
>
>
>
>
> Obviously sound advice. :)
>
> Apparently a glitch in my newsreader, which showed up the postings as new
> messages.
>
> BTW, did you have nothing better to do ?
>
>
Says the man who often posts 5 or 6 messages either devoid of content, or
demonstrably wrong. You know, it's as though your daily constitutional crap
doesn't end up in the bowl as it should, but rather makes its way on to c.l.f.
Still no working F77 demonstration of TRIM()?
cheers,
Rich
| |
| AeroSpace Ed 2006-03-23, 10:03 pm |
| Rich Townsend wrote:
> robin wrote:
>
> Says the man who often posts 5 or 6 messages either devoid of content, or
> demonstrably wrong. You know, it's as though your daily constitutional
> crap doesn't end up in the bowl as it should, but rather makes its way on
> to c.l.f.
>
> Still no working F77 demonstration of TRIM()?
>
> cheers,
>
> Rich
I'm a 42 year old engineer that's been programming in Fortran since the 70's
and I think I'm lost in life, heading down a long road of depression. I
seem to be looking forward to c.l.f in the evenings watching this buffoon
named 'robin' act like a 5 year old. I'm convinced he's mentally unstable.
I just roll on the floor laughing at the swill he posts.
I too am awaiting his world in-famous version of TRIM()!!
Ed
| |
|
| Rich Townsend wrote in message ...[color=darkred]
>robin wrote:
<nonsense elided>
You answered my rhetorical question.
|
|
|
|
|