cmplx and complex intrinsics

Steve Kargl sgk@troutmask.apl.washington.edu
Fri May 4 20:54:00 GMT 2007


On Fri, May 04, 2007 at 03:21:22PM -0500, Brian Barnes wrote:
> 
> I was debugging a program this afternoon (I didn't write the
> offending code, honest), and found that the returned value was only
> complex*8, single precision, when I supplied double precision arguments.

Unfortunately, this is the correct behavior as specified by the Fortran
standards.

program a
   integer, parameter :: dp = kind(1.d0)
   real(dp) :: x = 1._dp / 10._dp, y = 1._dp / 3._dp
   complex(dp) z
   z = cmplx(x,y)     ! This is single precision result that is
                      ! assigned to the double complex z.
   print *, z
   z = cmplx(x,y,dp)  ! This is a double precision result.
   print *, z
end program a

troutmask:kargl[206] gfc -o z h.f90
troutmask:kargl[207] ./z
 ( 0.100000001490116, 0.333333343267441)
 ( 0.100000000000000, 0.333333333333333)

> I solved the problem by using the "complex" intrinsic, which is currently
> undocumented for gfortran (!).

Whoops.  That's a bug.

To solve your problem with standard conforming, portable code, use
the 3rd optional argument to cmplx.

> I could have used "dcmplx", but actually
> figured out what was going on by reading g77 docs and I just tried
> "complex" figuring that it would be present in gfortran, which it was.  It
> seems that cmplx and complex in gfortran function exactly as described in
> the g77 docs.
> 
> http://gcc.gnu.org/onlinedocs/gcc-3.4.6/g77/Cmplx-Intrinsic.html
> http://gcc.gnu.org/onlinedocs/gcc-3.4.6/g77/Complex-Intrinsic.html
> 
> I just thought I'd write the list and see what the story was on all this.
> 
> My questions:
> Is "complex" deprecated or obsolete in gfortran?

No. It's not document, yet.  It also isn't specified by the standard.

> Should I be using dcmplx instead?

No. Use the 3rd optional argument to cmplx.  See above.

> Should documentation for complex be added?

Yes.

> Should I expect cmplx to return a double precision value when supplied
> with double precision input, and possibly there is a bug here?

See the above for the correct usage.  In looking at gfortran.info,
it appears that a better description of the return type is needed.

-- 
Steve



More information about the Fortran mailing list