Re: Caught out by cmplx

"James Van Buskirk" <not_valid@xxxxxxxxxxx> wrote in message news:hb27ru$ee7$1@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx
| "albert" <acp693@xxxxxxxxxxx> wrote in message
| news:387c5515-d35c-4ff6-a9a9-dc6b82be849b@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
| > I recently discovered that the precision of my code was being
| > compromised by my use of the intrinsic function Cmplx. The output of
| > this function doesn't assume the precision of the inputs to it, as far
| > as I have seen most other functions such as Abs, Real, Aimag, etc. do
| > so. One has to state the precision explicitly with an extra input.
| > I have fixed the problem in my code by replacing Cmplx with Dcmplx.
| > Does anyone know why the decision was made to let Cmplx default to
| > single precision irrespective of the precision of it's inputs?
| There are a couple of reasons. CMPLX, like REAL, can convert variables
| of the same type to different kinds. Also CMPLX was defined to
| return a single-precision complex result in f77 because f77 didn't
| define a double precision complex kind. If this were changed with
| f90, programs would behave differently and this would violate
| compatibility.

Compatability with F77 could be maintained as well as providing
a proper generic CMPLX, merely by providing an option.

That could (and should) have been done from F90, when generic functions
were introduced.