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>