Re: LEAST-POSITIVE-<mumble>-FLOAT

[hilfingr%tully.Berkeley.EDU@berkeley.edu (Paul Hilfinger)]

> Bob Mathis has some knowledge of how this issue was resolved in the ADA
> world.  How about it Bob? any clues?

Having participated in most of the language reviews and maintenance of
Ada, I think I can make a definitive statement on this question.  Do
NOT, under any circumstances, look to the Ada Standard for hints on
how to handle floating point arithmetic.  The Standard was an attempt
to define a semantics that conformed to all existing hardware.  As a
result, the properties one can deduce from the Ada semantics about
real arithmetic---in particular, about constants defined by the
language---are extremely weak and nearly useless.  Indeed, as far as
denormalized numbers are concerned, the interpretation  of some of the
constants is still under discussion.  Denormalized numbers fall into
the crack in the semantics that includes "everything that isn't a
model number," which means numbers with more precision than required
by the model, infinities, and NaNs.  As a result, they are tolerated,
but nothing specifically is said about them.

As for the interpretation of LEAST-POSITIVE-<mumble>-FLOAT, it seems
to me that the POSSIBILITY of traps is a red herring.  IEEE arithmetic
also provides for a trap on an inexact result; there are cases where
it is interesting to know that such a result has been produced.  Does
the fact that such a trap MIGHT be enabled raise questions about
whether (/ 1.0 3.0) must have a defined result in the case where the
trap is not enabled?  If we look at the underflow trap the same way---
as indicating places in which precision is lost for a particular
reason that is sometimes but not always of interest---it seems that we
should consider the least denormalized numbers as the appropriate values
for LEAST-POSITIVE-etc.  

As a (perhaps unnecessary) aside, I get a bit nervous seeing arguments
based on what a particular piece of hardware does.  IEEE arithmetic is
a user interface standard, and says nothing of the division of labor
between chip and interface software.  A piece of "IEEE floating-point
hardware" is entitled, for example, to produce traps at places not
mandated by the standard, as long as the accompanying support software
fills in the semantics required by the standard.

Paul Hilfinger
UC Berkeley
Hilfinger@Berkeley.EDU