How can I use dreal and dimag in a f90 program? 
Author Message
 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



Sun, 20 Jul 2008 21:02:34 GMT  
 How can I use dreal and dimag in a f90 program?

Quote:
>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>



Sun, 20 Jul 2008 21:14:20 GMT  
 How can I use dreal and dimag in a f90 program?
f is a complex(16).  I think I should change to qreal and qimag. f77
does complain about it.

Ed



Sun, 20 Jul 2008 21:46:08 GMT  
 How can I use dreal and dimag in a f90 program?

Quote:

>  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



Sun, 20 Jul 2008 23:56:32 GMT  
 How can I use dreal and dimag in a f90 program?

Quote:
> f is a complex(16).  I think I should change to qreal and qimag. f77
> does complain about it.

Aha!  When you use the new, conforming, kind numbers, there is
a little twist regarding complex variables.  In the ifort kind
type numbering scheme, the kind type parameter for single-precision
variables is 4, for double-precision is 8, and for quad-precision
is 16.  Thus what might have been in the old, nonconforming scheme,
real*4 and complex*8 translate to real(4) and complex(4); real*8
and complex*16 translate to real(8) and complex(8); finally
real*16 and complex*32 translate to real(16) and complex(16).

Hardwiring the kind numbers as I would assume you are doing is
not a good idea.  You would be better off, in my opinion, to
create a module for your kind numbers.  One such is:

module mykinds
   implicit none
   integer, parameter :: sp = selected_real_kind(6,30)
   integer, parameter :: dp = selected_real_kind(15,300)
   integer, parameter :: ik1 = selected_int_kind(2)
   integer, parameter :: ik2 = selected_int_kind(4)
   integer, parameter :: ik4 = selected_int_kind(9)
   integer, parameter :: ik8 = selected_int_kind(18)
end module mykinds

program test
   use mykinds
   implicit none

   write(*,*) huge(1.0_sp)
   write(*,*) huge(1.0_dp)
   write(*,*) huge(1_ik1)
   write(*,*) huge(1_ik2)
   write(*,*) huge(1_ik4)
   write(*,*) huge(1_ik8)
end program test

C:\Program Files\Intel\Compiler60\James\clf\kinds>ifort /c /stand:f95
kinds.f90
Intel(R) fortran Compiler for 32-bit applications, Version 9.0    Build
20060120
Z Package ID: W_FC_C_9.0.029
Copyright (C) 1985-2006 Intel Corporation.  All rights reserved.

C:\Program Files\Intel\Compiler60\James\clf\kinds>link kinds.obj
Microsoft (R) Incremental Linker Version 6.00.8447
Copyright (C) Microsoft Corp 1992-1998. All rights reserved.

C:\Program Files\Intel\Compiler60\James\clf\kinds>kinds
  3.4028235E+38
  1.797693134862316E+308
  127
  32767
  2147483647
   9223372036854775807

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



Mon, 21 Jul 2008 02:45:25 GMT  
 How can I use dreal and dimag in a f90 program?

Quote:

>>  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

 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



Mon, 21 Jul 2008 04:09:50 GMT  
 How can I use dreal and dimag in a f90 program?

Quote:

> 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



Mon, 21 Jul 2008 05:08:48 GMT  
 How can I use dreal and dimag in a f90 program?


Quote:
> 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



Mon, 21 Jul 2008 06:25:06 GMT  
 How can I use dreal and dimag in a f90 program?

Quote:


>>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.

Not in the case of REAL, where KIND MUST be specified.


Mon, 21 Jul 2008 08:15:19 GMT  
 How can I use dreal and dimag in a f90 program?

Quote:

>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.


Mon, 21 Jul 2008 08:15:20 GMT  
 How can I use dreal and dimag in a f90 program?

Quote:
> Use the generic procedure names REAL and AIMAG.

Wrong answer: the problem lay in his declarations of
complex variables.

Quote:
> 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



Mon, 21 Jul 2008 11:32:23 GMT  
 How can I use dreal and dimag in a f90 program?
Hello,

<snip>

Quote:
>>What am I missing?

> 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.



Mon, 21 Jul 2008 11:34:55 GMT  
 How can I use dreal and dimag in a f90 program?

Quote:

> Hello,




> <snip>

>>> What am I missing?

>> 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.

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



Mon, 21 Jul 2008 12:14:44 GMT  
 How can I use dreal and dimag in a f90 program?

Quote:


> > 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?

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



Mon, 21 Jul 2008 13:35:48 GMT  
 How can I use dreal and dimag in a f90 program?

Quote:



>>>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?

> 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



Mon, 21 Jul 2008 13:55:47 GMT  
 
 [ 24 post ]  Go to page: [1] [2]

 Relevant Pages 

1. Using CGI module with 'canned queries'

2. HELP: need reference on OO programming using F90

3. Using SLATEC F77 library routine from F90 program

4. debugging F90 programs using gdb on compaq-alpha

5. Debugging F90 programs under Solaris (using dbx)

6. dreal, cdabs, etc. in f2c

7. Alternative for DREAL?

8. CA Cans VO ?

9. It's not bad canned meat...

10. It's not bad canned meat...

11. It's not bad canned meat...

12. It's not bad canned meat...

 

 
Powered by phpBB® Forum Software