J3/97-211 Date: August 8, 1997 To: J3 From: DIN/Wolfgang Walter & Baker Kearfott Subject: Recommendations for the Development of Interval Arithmetic in Fortran 2000 ------------------------------------------------------------------------- WG5 N 1303 Recommendations for the Development of Interval Arithmetic in Fortran 2000 1. Investigate the possibility of extending the Fortran character set, e.g. by adding square brackets [ and ] (which are useful for many reasons, most of them not connected with intervals) and possibly other characters. For characters that are not universally representable, investigate alternative, universally portable representations using only the current Fortran character set. 2. Introduce "interval types" in a way that is orthogonal to the existing way of specifying numeric intrinsic types. One way of doing this is to introduce a new type parameter (which could be termed FORM type parameter) in addition to the kind type parameter for REAL - in such a way that it can be extended to other intrinsic types, e.g. COMPLEX and INTEGER. (Please also refer to document WG5 V16.) This will allow building a mirror image of the specification structure of the existing numeric types for the new interval types (in the long term). Implementation restrictions on the set of admissible kind-parameter values for interval types might be allowed initially, and might be disallowed in a future standard. An example of the intended kind of syntax is: REAL ( KIND = KIND(0.0D0), [ FORM = ] INTERVAL ) (This new type parameter could also be used for other purposes, e.g. to specify a type for fuzzy logic.) The introduction of completely new intrinsic type statements for interval types is viewed as being more controversial, a bigger burden on the language, and not easily extensible. 3. Add the new operators required for interval arithmetic in such a way that they have their natural precedence. In particular, the new relational operators should have the same precedence as the existing relationals, and the operators for "intersection" and "interval hull" should have higher precedence than these. Since this constitutes a change of the language that will potentially change the interpretation of existing programs, it is proposed that specific measures, which could be in the spirit of the following two, be taken to greatly reduce or eliminate the impact of this incompatibility: a) reduce the likelihood of collisions with operator names in existing code by choosing more explicit, interval-specific names, and/or b) make new interval operators (and other interval features) available only via special action on the part of the programmer, e.g. when a use statement for an intrinsic interval module is specified. 4. In the hope of resolving the discussions about the two seemingly incompatible semantic models of interval arithmetic, we would like to suggest another viewpoint. Let us define the two models as a) the "set-theoretic" model where all operands/arguments are interpreted as independent sets, and b) the "functional" model, where operands/arguments which are formally the same variable are interpreted as being dependent sets. We strongly believe that the fundamental definition of the elementary operators and intrinsic functions should follow the set-theoretic model and thus the runtime semantics of these individual operations should be unambiguously defined. However, we also believe that tighter interval enclosures produced by applying the functional model to whole expressions or sections of code are highly desirable in many cases. We propose that optimizations (e.g. algebraic simplifications) which are possible under the functional model be explicitly allowed - conceptually during a preprocessing phase - and that the stricter set-theoretic model be applied to the code resulting from this phase. We also believe that the user should be given the power to require strict interpretation of his/her code according to the set-theoretic model, i.e. it should be possible to prohibit optimizations which are possible under the functional model, at least globally, but possibly also locally by other selective means. --------------------------------------------------------------- R. Baker Kearfott, rbk@usl.edu (318) 482-5346 (fax) (318) 482-5270 (work) (318) 981-9744 (home) URL: http://interval.usl.edu/kearfott.html Department of Mathematics, University of Southwestern Louisiana USL Box 4-1010, Lafayette, LA 70504-1010, USA ---------------------------------------------------------------