[HARLEQUIN][Common Lisp HyperSpec (TM)] [Previous][Up][Next]


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.


[Starting Points][Contents][Index][Symbols][Glossary][Issues]
Copyright 1996, The Harlequin Group Limited. All Rights Reserved.