CLHS: Issue FLOATING-POINT-CONDITION-NAMES Writeup

#

## Issue FLOATING-POINT-CONDITION-NAMES Writeup

    Forum:		Cleanup
    Issue:		FLOATING-POINT-CONDITION-NAMES
    References:	CLtL, Section 12.10 "Implementation Parameters" (for floats)
    		CLtL, P.448 "*features*"
    		IEEE Standard for Binary Floating-Point Arithmetic
    Related Issues:	FLOAT-UNDERFLOW
    		ERROR-CHECKING-IN-NUMBERS-CHAPTER
    Category:	ADDITION
    Edit History:   V1, 30 Oct 1989, JonL White
    	        V2, 4 Dec 1990, Kent M. Pitman (amendments per X3J13)

    Problem Description:

    The currently proposed error system contains names for three conditions
    related to floating-point operations: floating-point-underflow,
    floating-point-overflow, and division-by-zero.  Probably a majority
    of implementation will be running on machines that support the IEEE
    floating point standard; but there is no name for the remaining two out
    of the five mandated trapping conditions, namely floating-point-inexact
    and floating-point-invalid-operation.

    Furthermore, even though the condition names may appear in an image,
    it is not clear that such traps are enabled at every point in time.
    The IEEE standard specifies that user-level programs ought to have
    the capability of selectively enabling or disabling its five traps;
    and other implementations may run on a variety of hardware configurations
    for which the traps possible vary from host to host.  However, there is
    no current way for user-code to ask (1) what conditions are in fact
    supporting floating-point traps, nor to ask (2) just what traps are
    currently active

    Note that some very simple implementations might not be able to cause
    trapping even for floating-point-underflow;  and in other implementations,
    the relevant traps may vary on a host-to-host basic, depending on what
    particular optional hardware is available on that host.  For example,
    Sun3 workstations come  in three configurations: one with only software
    floating-point support, one with a Motorola MC68881 attached co-processor,
    and one with both an MC68881 and a Weitek Floating Point "Accelerator";
    the increasing hardware complement gives rise to an increasing number of
    implementation-specific traps.  Even within the IEEE standard, it is
    possible for a conforming implementation to make a refinement of the five
    suggested traps [the MC68881 partitions one of the traps into three,
    giving a total of eight]; so even though one knows that an implementation
    is IEEE compatible, it still makes sense to ask what conditions are
    supportable as floating-point traps.

    Proposal (FLOATING-POINT-CONDITION-NAMES:X3J13-NOV-89)

      1. Add FLOATING-POINT-INVALID-OPERATION and FLOATING-POINT-INEXACT
         as conditions which are sub-conditions of ARITHMETIC-ERROR.

    The intent is that if condition FOO is a currently enabled floating
    point trap, then whenever that particular situation arises the
    system will arrange to signal the Lisp condition FOO.  The means for
    enabling and disabling traps is not addressed in this proposal.

    Proposal (FLOATING-POINT-CONDITION-NAMES:ADD-MINIMAL-IEEE)

      1. Add FLOATING-POINT-INVALID-OPERATION and FLOATING-POINT-INEXACT
         as conditions which are sub-conditions of ARITHMETIC-ERROR.
      2. Add a global parameter SUPPORTED-FLOATING-POINT-CONDITIONS which
         is to contain a list of all the condition names that can, in that
         implementation, be enabled as floating-point traps; this is to
         be an "implementation revealing" parameter.
      3. Add a function of no arguments ENABLED-FLOATING-POINT-TRAPS which
         returns a list of condition names for all currently enabled
         floating point trapping conditions.

    The intent is that if condition FOO is a currently enabled floating
    point trap, then whenever that particular situation arises the
    system will arrange to signal the Lisp condition FOO.  The means for
    enabling and disabling traps is not addressed in this proposal.

    Rationale:

    Many Common Lisp implementations do in fact run on hardware that
    supports the IEEE floating-point standard;  a minimal requirement
    for porting between these implementations is that they all use the
    same name for the five IEEE-mandated floating-point conditions.
    Since at least some implementations will provide means for selective
    enabling and disabling of various floating-point traps, then the
    user must be able to query the system to find out what the current
    state is, and what states are supportable.

    Current Practice:

    Lucid Common Lisp supports this much; moreover, it uses SETF on
    (ENABLED-FLOATING-POINT-TRAPS) as the primary means to alter the
    currently-enabled traps.

    Cost to implementors:

    Trivial.

    Cost to users:

    None; this is an upward-compatible addition.

    Benefits:

    Portability of a greater amount of user code; portability of "skills",
    since IEEE support is so common.

    Aesthetics:

    It is better for all IEEE implementations to use the same names for
    these conditions, rather than have them vary from one to another.
    It is also probably better for non-IEEE implementations to use the
    IEEE condition names where appropriate, just to minimize the
    conceptual overload.

    Discussion:

    If an implementation is to claim full IEEE support, then it ought to
    provide some means of enabling and catching these five IEEE-mandated
    traps.  Then it would be appropriate to put :IEEE-FLOATING-POINT on
    the list *FEATURES* (see CLtL, P.448).

    Moon and JonL privately discussed some means for enabling and
    disabling various floating-point traps, back in June 1989 when the
    float-underflow proposal was under discussion; they came to the
    conclusion that "getting the design right and efficient" was more
    than a few minutes worth of work, and so postponed further work on it.

    [The IEEE standard apparently goes by the name of ANSI-IEEE Std 754-1985;
    my working copy is Draft 10.0 from 1982.  I don't think there are great
    variances between them. -- JonL --]

Copyright 1996-2005, LispWorks Ltd. All rights reserved.