Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

gfortran documentation for AIMAG

27 views
Skip to first unread message

James Van Buskirk

unread,
Dec 8, 2010, 1:19:52 PM12/8/10
to
I had intended to cover AIMAG and REAL together but it seems that
REAL is much more complex that AIMAG so I separated this small post
out here.

Consider the following program:

C:\gfortran\clf\quadtest>type aimagtest.f90
program aimagtest
use ISO_FORTRAN_ENV
implicit none
intrinsic aimag
intrinsic dimag
intrinsic imag
intrinsic imagpart
complex(REAL_KINDS(1)) c4
complex(REAL_KINDS(2)) c8
complex(REAL_KINDS(3)) c10
complex(REAL_KINDS(4)) c16

c4 = (1,2)
c8 = (3,4)
c10 = (5,6)
c16 = (7,8)
write(*,*) aimag(c4)
write(*,*) aimag(c8)
write(*,*) aimag(c10)
write(*,*) aimag(c16)
! write(*,*) dimag(c4)
write(*,*) dimag(c8)
! write(*,*) dimag(c10)
! write(*,*) dimag(c16)
write(*,*) imag(c4)
write(*,*) imag(c8)
write(*,*) imag(c10)
write(*,*) imag(c16)
write(*,*) imagpart(c4)
write(*,*) imagpart(c8)
write(*,*) imagpart(c10)
write(*,*) imagpart(c16)
call crsub('aimag',aimag,c4)
call zdsub('dimag',dimag,c8)
call crsub('imag',imag,c4)
call crsub('imagpart',imagpart,c4)
end program aimagtest

subroutine crsub(label,fun,x)
implicit none
character(*) label
interface
function fun(x)
implicit none
complex, intent(in) :: x
real fun
end function fun
end interface
complex x

write(*,*) label//'(',x,') = ',fun(x)
end subroutine crsub

subroutine zdsub(label,fun,x)
implicit none
character(*) label
interface
function fun(x)
implicit none
complex(kind(1.0d0)), intent(in) :: x
double precision fun
end function fun
end interface
complex(kind(1.0d0)) x

write(*,*) label//'(',x,') = ',fun(x)
end subroutine zdsub

C:\gfortran\clf\quadtest>gfortran aimagtest.f90 -oaimagtest

C:\gfortran\clf\quadtest>aimagtest
2.0000000
4.0000000000000000
6.0000000000000000000
8.0000000000000000000000000000000000
4.0000000000000000
2.0000000
4.0000000000000000
6.0000000000000000000
8.0000000000000000000000000000000000
2.0000000
4.0000000000000000
6.0000000000000000000
8.0000000000000000000000000000000000
aimag( ( 1.0000000 , 2.0000000 ) ) = 2.0000000
dimag( ( 3.0000000000000000 , 4.0000000000000000 ) ) =
4.000000000
0000000
imag( ( 1.0000000 , 2.0000000 ) ) = 2.0000000
imagpart( ( 1.0000000 , 2.0000000 ) ) = 2.0000000

This shows that gfortran treats IMAG and IMAGPART as generic names
that mean the same thing as AIMAG. This is not the same thing as
having a specific name, IMAG for example, that takes COMPLEX
arguments of any KIND because that is a property of generic names,
not specific names. So I think that IMAG and IMAGPART should be
up there under the Syntax header along with generic name AIMAG.

Also the above example shows that AIMAG, IMAG, and IMAGPART are all
specific names that take COMPLEX(4) arguments and return a REAL(4)
result. Thus the KIND numbers should be added for these names
under the Specific names header as they are already for DIMAG. Also
AIMAG as a specific name is standard in at least f95 and so should
not be marked as a GNU extension under the Specific names header.

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


glen herrmannsfeldt

unread,
Dec 8, 2010, 3:18:44 PM12/8/10
to
James Van Buskirk <not_...@comcast.net> wrote:
> I had intended to cover AIMAG and REAL together but it seems that
> REAL is much more complex that AIMAG so I separated this small post
> out here.

Ha Ha Ha (on the REAL is much more COMPLEX part.)

Personally, though maybe I am the only one, I don't like the double
use of REAL. That is, as both the real part of a complex value,
and for conversion to (a specific KIND of) REAL type.

Now, it wouldn't be so bad if the types were consistently used
for the conversion functions, but they aren't. INT is used,
not INTEGER, for integer kind conversion, and CMPLX, not COMPLEX,
for complex kind conversion. Okay, LOGICAL is actually used
for that kind conversion, though normally there isn't any other
use for that logical conversion.

-- glen

0 new messages