[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue: FLOAT-UNDERFLOW (version 2)
- To: Moon@STONY-BROOK.SCRC.Symbolics.COM
- Subject: Issue: FLOAT-UNDERFLOW (version 2)
- From: Jon L White <jonl@lucid.com>
- Date: Thu, 25 May 89 12:57:13 PDT
- Cc: CL-Cleanup@sail.stanford.edu
- In-reply-to: David A. Moon's message of Wed, 24 May 89 13:23 EDT <19890524172312.2.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM>
re: [Lucid's WITH-FLOATING-POINT-TRAPS]
The inability to converge on a design for such an elaborate feature is
precisely the reason for proposing the very simple feature.
The design may not be as elaborate or complex as you think. When you see
the synopsis of it below, I think you'll have to agree that a simple setting
of an implementation-dependent parameter yields the functionality of
WITHOUT-FLOATING-UNDERFLOW-TRAPS with only two differences:
(1) the syntax is superficially different
(2) the equivalent of WITH-FLOATING-UNDERFLOW-TRAPS comes
along with it.
So an implementation wanting to obey the WITH-FLOATING-POINT-TRAPS interface,
but having already implemented WITHOUT-FLOATING-UNDERFLOW-TRAPS, could in
fact support the former by a simple use of the latter.
re: Also note that underflow is the _only_ exception that some applications
have a very strong need to enable while at the same time other applications
have a very strong need to disable. Thus just the simple feature gets
us most of the way towards perfection.
So why are these "some" applications so much more worthy than the others
that "have a very strong need" to selectively enable and disable the
overflow trap? [Using ieee floating-point, it is very useful at times to
admit positive and negative infinity representations, which is what the
untrapped overflow gives you].
What makes me a bit leary of this proposal, at this stage of the game,
is that I thought we had agreed to close down Cleanup for new proposals,
in order to concentrate our efforts of finishing the large amount of
work already started but not completed. For things previously discussed,
and which are clearly non-controversial, I see no problem. Now, the issue
of floating-point extremals was discussed briefly after I brought up the
issue of denormalization (over a year ago?), and got replies from Cassels
at Symbolics.com, Steele at Think.com and Hilfinger at Berkeley.edu
[that discussion might have been on Common-Lisp@SAIL rather than on
CL-Cleanup@SAIL]; at least it seemed there was consensus on that matter.
But the larger picture of treatment of floating-point traps just didn't
get discussed.
Anyway, before formalizing a CLeanup proposal [which I fear would be
moot at this late a date], let me get your reactions to a description
of the relevant features from Lucid Common Lisp:
(1) SUPPORTED-FLOATING-POINT-CONDITIONS -- An implementation-dependent
defconstant which typically varies from port to port; holds the list
of conditions which __can be__ supported as floating-point traps.
These are all condition names in the (extended) error system. For
example, ports using the MC68881 chip typically have:
floating-point-inexact
floating-point-overflow
floating-point-underflow
floating-point-OutOfDomain
floating-point-NaN
floating-point-UnorderedComparison
division-by-zero
Other ports might have only division-by-zero, floating-point-underflow,
and floating-point-overflow. Frequently these are continuable
conditions, but that varies with the degree of difficulty in restarting
a floating-point co-processor.
(2) ENABLED-FLOATING-POINT-TRAPS -- A function of no arguments which
Returns a list of all the floating-point condition names currently
enabled for error trapping. These names will be a subset of those
on SUPPORTED-FLOATING-POINT-CONDITIONS. A SETF method is provided
for this function as the means of explicitly setting the traps. [Of
course, certain software functions need to inspect the established
state too -- it isn't merely a blind poking of the control register
of a floating point chip.]
(3) WITH-FLOATING-POINT-TRAPS -- a macro for temporary setting of floating
point trapping conditions [typically, the temporary setting of traps
can be done in an implementation-dependent way that is much more
efficient than just saving and restoring (ENABLED-FLOATING-POINT-TRAPS)]
(defmacro with-floating-point-traps ((enable-list disable-list) &body body)
....)
where the 'enable-list' and 'disable-list' are evaluated. The traps
enabled during the execution of the body are:
(UNION <enable-list>
(SET-DIFFERENCE (ENABLED-FLOATING-POINT-TRAPS) <disable-list>))
Sample uses might be:
(with-floating-point-traps
('(floating-point-underflow)
supported-floating-point-conditions)
...
... ;all floating-point traps turned off except underflow
...)
(with-floating-point-traps
('()
'(floating-point-underflow))
...
... ;underflow turned off; all others left alone.
...)
I would expect controversy about the syntax of WITH-FLOATING-POINT-TRAPS;
and I would expect that someone would want to waste our time arguing how
much detail we would need in the specification of the defconstant
SUPPORTED-FLOATING-POINT-CONDITIONS.
-- JonL --