X3J3/96-095
Date: May 13, 1996
To: X3J3
From: Loren Meissner
Subject: Extend Initialization of Complex Variables
0094
Extend Initialization of COMPLEX Variables
<KEYWORDS> Initialization, Named Constant, COMPLEX
<STATUS> Registered
<TARGET>
<SUBGROUP>
<VERSION> 2
<REQUIREMENT>
Permit a complex constant with a named constant as either the real part or
the imaginary part (or both) [in an Initialization Expression].
</REQUIREMENT>
<JUSTIFICATION>
Applications in such fields as electrical engineering and optics often make
extensive use of complex numbers. It frequently happens that a particular real
value is required both as a real constant and as the real or imaginary part of a
complex constant value; the current standard requires that the same literal
constant must be written twice, because a named constant is not permitted as a
part of a complex constant:
real, parameter :: Omega = 1.23e6
complex, parameter :: J_Omega = (0.0, 1.23e6)
This can lead to programming errors.
A constant expression of complex type can be constructed with the intrinsic
function CMPLX where either or both of the arguments are named constants.
However, such an expression is not permitted for initialization.
Paper 96-042 suggests permitting a named constant within a complex constant
in an initialization expression.
An alternative, also suggested in 96-042, is to permit the elemental
intrinsic function CMPLX in initialization expressions, with arguments that are
initialization expressions of integer or real type. This would be an exception
to the rule that requires integer or character arguments and results for
elemental intrinsic functions in initialization expressions. The suggested
implementation given below is based on extending the form of complex constants
rather than that of initialization expressions.
</JUSTIFICATION>
<SUGGESTED IMPLEMENTATION>
Permit any complex constant in an initialization expression to have a named
constant as its real or imaginary part (or both). Thus the earlier example could
be written as follows:
real, parameter :: Omega = 1.23e6
complex, parameter :: J_Omega = (0.0, Omega)
POSSIBLE SYNTAX:
Invent the new term "_complex-mixed-constant_":
_complex-mixed-constant_ is ( _constant-part_ , _constant-part_ )
_constant-part_ is _signed-int-literal-constant_
or _signed-real-literal-constant_
or _named_constant_
Constraint: At least one constant part must be a named constant {to
avoid syntactic ambiguity with _complex-literal-constant_ }.
Expand item (1) in the definition of initialization expression to:
(1) A constant or subobject of a constant, or a complex mixed constant,
ALTERNATIVE: Permit a complex mixed constant (as just described) in all
contexts that permit a named complex constant. This would be more general and
less irregular, but would need to be carefully checked for possible syntactic
ambiguity.
Alternative syntax: Define "_complex-mixed-constant_" as above. Do not
change the definition of initialization expression. Change the definition of
"_named-constant_" to:
_named-constant_ is _name_
or _complex-mixed-constant_
</SUGGESTED IMPLEMENTATION>
<ESTIMATED IMPACT>
Improved program reliability for certain applications with data of type
complex.
</ESTIMATED IMPACT>
<SUBMITTED BY>
Loren Meissner
2 Kerr Ave
Kensington CA 94707
LPMeissner@msn.com
</SUBMITTED BY>
<HISTORY>
<EVENT> February 1996, meeting 136; submitted 96-042
<EVENT> May 1996, meeting 137
</HISTORY>
</FORTREQ>