ISSUE: IEEE Float Conformance REVISION HISTORY: Version 1, 17 January 1994, Rob MacLachlan STATUS: RELATED ISSUES: IEEE Float Exception Trapping, Allow IEEE Comparisons CATEGORY: Change/Clarification PROBLEM DESCRIPTION: The IEEE standards for floating point arithmetic are highly valued by numeric programmers: -- Standard rounding semantics, precision and exponent range are defined, ensuring that basic arithmetic operations give the same results on all conformant hardware. -- Additional special values are supported which give well-defined results to operations that don't have a precise finite result (see "IEEE Float Exception Trapping".) Because of these advantages, IEEE floating point arithmetic has become virtually universal. Now that IEEE floating point is ubiquitous, programmers are beginning to routinely take advantage of the IEEE special values and other features unique to the IEEE floating point representation. Unless Dylan provides IEEE semantics (or at least allows it as an extension), numeric programs cannot be written in a modern style, and Dylan will be dismissed for applications with any significant numerical component. The success of IEEE floating point would not be a problem where it not for the fact that the success is possibly not universal. Some hardware doesn't support IEEE floats, either because: -- It was designed before the standard was developed, or -- The hardware designers decided that the IEEE functionality was too costly to implement, and was not necessary in the intended application. PROPOSAL: Four alternatives are proposed: LOWEST-COMMON-DENOMINATOR: Dylan programs can't depend on much of anything about floating point arithmetic. Precision, range and rounding are undefined. The consequences of overflow, underflow or division by zero are undefined. IEEE features can't be used. USE-IEEE-SEMANTICS: Dylan programs can depend on floats being implemented according to the IEEE standard. IEEE features can be used, and a portable standard library will be specified for accessing any universal IEEE features which are not implicitly accessed by the existing arithmetic and comparison operations, for example a predicate to test whether a float is a NaN. STANDARD-IEEE-BINDING: If a Dylan implementation declares that it is IEEE conformant, then it implements USE-IEEE-SEMANTICS, otherwise it implements LOWEST-COMMON-DENOMINATOR. In effect, this amounts to a parameterized standard, or a standard subset. HYBRID-OBJECT-FRAMEWORK: Require the classes , and to be the corresponding IEEE float format if those classes are defined. Operations on these classes obey USE-IEEE-SEMANTICS. Even in IEEE implementations, some of these classes (probably extended) may be omitted. Specify that the exponent markers S, D and X indicate IEEE single, double and extended floats. If the corresponding float class is not implemented, then a error will be signalled at parse time. Clarify that the E exponent marker in a literal specifies a constant. The class of e.g. 1e0 or 1.0 is not necessarily any of the IEEE float classes, but rather some implementation-dependent subclass of . Non-IEEE floats used portably as long as LOWEST-COMMON-DENOMINATOR behavior is expected. E literals are legal in any Dylan, and Every Dylan must implement some class of float. RATIONALE: Rationales for each alternative: LOWEST-COMMON-DENOMINATOR: This option is simplest, and meets the needs of most casual uses of floats. Code that obeys the restrictions would be completely portable, but meeting the restrictions is impossible, since nothing is guaranteed about range or precision. USE-IEEE-SEMANTICS: This option provides a clear definition of floating point semantics, and allows use of IEEE features in Dylan. This is a very strong portability guarantee, but ignores the possibility of non-IEEE hardware. Perhaps hardware IEEE float support is now so universal that we can assume its presence. STANDARD-IEEE-BINDING: This is the approach usually taken by languages that address the issue. The IEEE binding is a separate document that further constrains the standard and specifies additional features. This alternative precisely specifies IEEE semantics without entirely precluding the possibility of n on-IEEE implementations. HYBRID-OBJECT-FRAMEWORK: This is effectively equivalent to STANDARD-IEEE-BINDING, except that it is more concrete, and clearly specifies how a non-IEEE-dependent program can be written. This alternative also differs somewhat in its language definition philosophy, in that the uncertainty is expressed in language concepts rather than meta-linguistic standardization concepts. The HYBRID-OBJECT-FRAMEWORK lies somewhere between STANDARD-IEEE-BINDING and USE-IEEE-SEMANTICS in its embrace of IEEE arithmetic. The IEEE standard is part of the core semantics, but casual users can write non-IEEE-dependent code by using the class and E qualifier (or no qualification.) EXAMPLES: COST TO IMPLEMENTORS: The only alternative with a major implementation cost is USE-IEEE-SEMANTICS, which makes implementation fairly impractical on non-IEEE hardware. COST TO USERS: -- LOWEST-COMMON-DENOMINATOR has significant cost to users, since they are denied access to IEEE features that can significantly increase the speed, clarity and robustness of numerical code. -- USE-IEEE-SEMANTICS has negligible cost to users unless they must run on non-IEEE hardware, in which case the cost is near-infinite. -- STANDARD-IEEE-BINDING can leave users somewhat confused about the degree to which they can depend on IEEE support and the way in which non-IEEE-dependent code must be written. -- HYBRID-OBJECT-FRAMEWORK gives clear control of the portability issues, but adds some extra complexity to the standard if IEEE hardware is already assumed universal. PERFORMANCE IMPACT: LOWEST-COMMON-DENOMINATOR has significant performance impact on numerical code. BENEFITS: Numeric programming in Dylan will be considered a serious possibility if IEEE support is defined. AESTHETICS: HYBRID-OBJECT-FRAMEWORK seems more OO than STANDARD-IEEE-BINDING. FUTURE FEATURES: Provides a framework for proposals that specify how to access particular IEEE features.