Re: Caught out by cmplx
- From: "robin" <robin_v@xxxxxxxxxxx>
- Date: Fri, 16 Oct 2009 02:31:18 GMT
"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.
.
- References:
- Caught out by cmplx
- From: albert
- Re: Caught out by cmplx
- From: James Van Buskirk
- Caught out by cmplx
- Prev by Date: Re: Caught out by cmplx (yet again)
- Next by Date: Re: Caught out by cmplx
- Previous by thread: Re: Caught out by cmplx
- Next by thread: Re: Caught out by cmplx (yet again)
- Index(es):
Relevant Pages
|