References: CLtL p.231
Related issues:LEAST-POSITIVE-SINGLE-FLOAT-NORMALIZATION (not written up),
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
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.
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
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.
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.
Lucid and Symbolics implement this proposal.
Cost to Implementors:
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
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.
Increased portability and correctness of floating point code.
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