(j3.2006) Asymmetry of REAL, CMPLX intrinsics

[Dan Nagle]

Hello,

I'm not convinced this is a problem.
Know the rules and play by them.

This is a semi-regularly recurrent discussion
in the public forums, and the consensus
seems to be to introduce a new intrinsic,
usually called complex() to handle the desired operation.
After all, we have mod() and modulus().

In any case, now is not the time.
I'm opposed to adding new features to f08,
we ought to be thinking of what,
of the little things other than co-arrays,
could be removed.

On Jan 7, 2008, at 6:21 PM, Van Snyder wrote:

On Mon, 2008-01-07 at 17:04 -0600, Bill Long wrote:
> This seems like a recurring discussion.
>
> REAL is really two different functions. One is type conversion that
> converts the argument to type real.  The other extracts the real  
> part of
> a complex value.  As is the case for the companion AIMAG, this is  
> not is
> not a type conversion.   CMPLX, on the other hand, is only a type
> conversion function.  I think the type conversion operations should  
> have
> similar rules, as is the case now.  The use of REAL as an extraction
> operation for complex arguments is sort of an oddball case that is
> reasonably treated differently.  I don't see the motivation for  
> changing
> this treatment, especially since it introduces a backward
> incompatibility.  Maybe we could modify the Description of REAL to be
> "Convert to type real or extract the real part of a complex value."

REAL and CMPLX both serve as both type and kind conversion functions.

REAL extracts the real part of a complex argument, or converts a real
argument to a different kind.

CMPLX composes a complex number from two real arguments, or converts a
complex argument to a different kind.

Where REAL extracts the real part of a complex argument, its result kind
is the same as the argument kind (assuming no KIND argument).  Otherwise
its result is default real (assuming no KIND argument).

Where CMPLX composes a complex result from two real arguments, its
result kind is NOT the same as the argument kind, it's default real kind
(assuming no KIND argument).  Where CMPLX has a complex argument, its
result type is also default real (again assuming no KIND argument).

Changing CMPLX to produce a result of the same kind as its arguments
where it's doing type conversion (assuming no KIND argument) would make
it symmetric to REAL, but would introduce an incompatibility with
Fortran 90 that would need to be announced.

> Cheers,
> Bill
>
>
> Van Snyder wrote:
>> If the argument of REAL is real and the KIND argument is not present,
>> the result kind is default real.
>>
>> If the argument of REAL is complex and the KIND argument is not  
>> present
>> the result kind is the kind of the argument.
>>
>> If the KIND argument of CMPLX is not present, the result kind is the
>> same as default real kind, no matter whether the X argument is real  
>> or
>> complex.
>>
>> For symmetry, it would be helpful if the result kind of CMPLX were  
>> the
>> same as the X argument kind, if the X argument is real, and default  
>> real
>> kind if the X argument is complex.
>>
>> It is probably too late to change this in 2008 (although I may  
>> submit a
>> comment).
>>
>> Are you in favor of the change at some unspecified time, or do you
>> object to the change no matter when it's attempted?
>>
>>
>

_______________________________________________
J3 mailing list
J3 at j3-fortran.org
http://j3-fortran.org/mailman/listinfo/j3

-- 
Cheers!

Dan Nagle