[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue: FLOAT-UNDERFLOW (version 2)
- To: Jon L White <jonl@lucid.com>
- Subject: Issue: FLOAT-UNDERFLOW (version 2)
- From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Wed, 24 May 89 13:23 EDT
- Cc: CL-Cleanup@sail.stanford.edu
- In-reply-to: <8905241515.AA13086@bhopal>
Date: Wed, 24 May 89 08:15:24 PDT
From: Jon L White <jonl@lucid.com>
Lucid 3.0 and later has LEAST-{NEGATIVE,POSITIVE}-NORMALIZED-<mumble>-FLOAT,
and in fact copied the names from Symbolics. These, and the prescription
that LEAST-{NEGATIVE,POSITIVE}-<mumble>-FLOAT be denormalized in
implementatons which support it, seem very non-controversial to me.
Thanks, I'll add that to the current practice section in the next version.
But WITHOUT-FLOATING-UNDERFLOW-TRAPS is too limited. The topic needs
more thought, because much more than "underflow" should be considered.
Lucid 3.0 and later has WITH-FLOATING-POINT-TRAPS, which takes two
lists of condition names relevant to floating point operations and
selectively enables or disables them (one list for "enablements", and
one for "disablements"). And I wouldn't like to bet on our being
able to achieve consensus on this design over the next few weeks,
even though I agree that it is an important topic.
The inability to converge on a design for such an elaborate feature is
precisely the reason for proposing the very simple feature. 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. By the way if you want to write
up a proposal for the Lucid WITH-FLOATING-POINT-TRAPS so we can discuss
it, that would be fine with me. But I will be very disappointed if the
end result is that we can't agree on it and do nothing at all.