#

## Issue FLOAT-UNDERFLOW Writeup

    Issue:         FLOAT-UNDERFLOW
    References:    CLtL p.231
    Related issues:LEAST-POSITIVE-SINGLE-FLOAT-NORMALIZATION (not written up),
                   ERROR-CHECKING-IN-NUMBERS-CHAPTER
    Category:      ADDITION and CLARIFICATION
    Edit history:  Version 1, 9-May-89, by Moon (suggested in January, but
                            the writeup was late)
                   Version 2, 23-May-89, by Moon (final cleanup for post-CLtL
                            changes to Common Lisp)
                   Version 3, 18-Jun-89, by Moon (update based on discussion
                            within the cleanup subcommittee)
    	       Version 4, 28-Jul-89, by Pitman (modify per X3J13 vote)
    Status: Passed FLOAT-UNDERFLOW:ADD-CONTROLS-1-2, June 1989

    Problem description:

      In implementations with denormalized floating point numbers (as in IEEE
      floating point), which are closer to zero than any non-zero normalized
      floating point numbers, should the LEAST-POSITIVE- and
      MOST-POSITIVE-XXX-FLOAT constants be the normalized or denormalized
      values?  Which is preferred depends on the application.  Note that in
      IEEE floating point, denormalized results are normally only produced
      as a result of underflow.

      Also, there is no portable way to control what happens when a floating
      point number underflows.  Sometimes this is an error, sometimes not.
      Indeed there is no mention at all of underflow or overflow in CLtL.
      Pending issue ERROR-CHECKING-IN-NUMBERS-CHAPTER does not mention floating
      point overflow or underflow.  Draft ANSI Common Lisp specifies error
      conditions named FLOATING-POINT-OVERFLOW and FLOATING-POINT-UNDERFLOW
      but does not specify the circumstances in which they are signalled and
      does not provide any way to suppress underflow checking.

    Proposal (FLOAT-UNDERFLOW:ADD-VARIABLES):

      1. Clarify that the existing LEAST-POSITIVE-XXX-FLOAT and
      LEAST-NEGATIVE-XXX-FLOAT constants are literally as defined, and
      therefore can be denormalized numbers in implementations that have
      denormalized numbers.

      2. Add the following constants, whose values are the normalized floating
      point numbers closest in value to (but not equal to) zero.  In
      implementations that don't have denormalized numbers, the values of these
      constants are the same as the values of the other constants.

        LEAST-NEGATIVE-NORMALIZED-DOUBLE-FLOAT [Constant]
        LEAST-NEGATIVE-NORMALIZED-LONG-FLOAT [Constant]
        LEAST-NEGATIVE-NORMALIZED-SHORT-FLOAT [Constant]
        LEAST-NEGATIVE-NORMALIZED-SINGLE-FLOAT [Constant]
        LEAST-POSITIVE-NORMALIZED-DOUBLE-FLOAT [Constant]
        LEAST-POSITIVE-NORMALIZED-LONG-FLOAT [Constant]
        LEAST-POSITIVE-NORMALIZED-SHORT-FLOAT [Constant]
        LEAST-POSITIVE-NORMALIZED-SINGLE-FLOAT [Constant]

    Rationale:

      Regularize current practice.

      The ANSI Common Lisp standard should be compatible with the widely used
      IEEE Floating Point standard.

      WITHOUT-FLOATING-UNDERFLOW-TRAPS is provided as a macro to allow
      implementation flexibility.  It could expand into HANDLER-BIND for
      FLOATING-POINT-UNDERFLOW, but in most implementations it will probably
      expand into implementation-dependent code that sets a hardware mode bit.

      Specifying "should signal" rather than "signals" or "might signal" for
      floating-point overflows and underflows seems the best balance between
      safety and implementation freedom.  It wouldn't harm the proposal to
      change it to one of the other two phrases.

    Current practice:

      Lucid and Symbolics implement this proposal.

    Cost to Implementors:

      Small.

      If there are implementations that currently consider storing only
      normalized quantities in the CLtL-specified variables, code that
      references those variables might need to be changed to refer to the
      new variable so that the existing variables can be changed to store
      unnormalized values.

    Cost to Users:

      Technically none.  Portable code cannot rely on this feature because
      it is currently inadequately specified.  Code which relies on a
      particular implementation's interpretation might have to be modified
      very slightly and recompiled.

    Cost of non-adoption:

      Continued confusion over the question of what is held by the
      existing LEAST-xxx variables.

    Performance impact:

      None.

    Benefits:

      Increased portability and correctness of floating point code.

    Esthetics:

      Neutral.

    Discussion:

      Earlier revisions of this proposal addressed other features which
      addressed the issues raised in the Problem Description in a more
      thorough way.  Included in version 3 was a proposal for a
      WITHOUT-FLOATING-UNDERFLOW-TRAPS form.  Discussion of those
      additional features was tabled for lack of time during the meeting
      where the vote was taken on this issue--and a proposal equivalent
      to this more limited proposal was approved since it was less
      controversial.

Copyright 1996-2001, Xanalys Inc. All rights reserved.