Re: Motion P1788/M003.01_Set_of_reals
On 2009-04-11 12:40:42 -0400, Michel Hack wrote:
> My view is that 754 conflates two concepts into one: "true" infinity
> as an ideal point in R*, and overflow within R. It has little choice
> because distinguishing them would require an extra bit somewhere, and
> possibly complicate implementations (at least in 1985). *}
But it is important to note that concerning the first concept, it
does it wrong. Indeed there's an important rule to follow: if f(x)
is mathematically defined (over R, R* or whatever) for some input x
and function f, the result must not depend on how f(x) is computed,
provided that all internal computations are exact. If you consider
IEEE 754 on R* (that is, ignore the division-by-zero exceptions),
then there's a problem with -0 = +0 and 1/-0 != 1/+0.
> IA does have a choice however: we are exercising it right now.
Doing what IEEE 754 does, i.e. sometimes regarding the infinity as
unsigned, sometimes as signed (in fact it does that for the zero,
when going from level 1 to level 2, but this is visible only on the
infinity), would not be acceptable for IA.
> *) Distinguishing true and false infinities would have been easy, as
> only a NaNcode bit would have had to be sacrificed (or nothing at
> all in DFP, which has higher redundancy). But this would also
> require distinguishing true (exact) and false (inexact underflow)
> zeros -- and that would require sacrificing either a precision bit,
> or truly complicate the encoding by making zero look like another
> kind of infinity (which one -- the true one or the false one, or
> both?).
Yes.
> Come to think of it, having BOTH types of zero use the extreme
> exponent encoding, and making a pattern of all-zeros a signalling
> NaN, could have done wonders for detecting uninitialised storage!
Well, in theory. This really depends on the language, the kind
of storage and the application. For instance, in C, initialized
floating-point values must be initialized to 0 by default (e.g.
if defined as static). Other languages may want to use sNaN by
default. BTW, MPFR initializes variables to NaN[*] and this has
been shown very useful in practice.
[*] MPFR doesn't make a difference between qNaN and sNaN, but it
doesn't support traps, and it always sets the NaN flag when the
result is a NaN. I don't think there is a practical problem with
this behavior.
--
Vincent Lefèvre <vincent@xxxxxxxxxx> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)