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.