[r6rs-discuss] Confusion over |p

From: William D Clinger <will>
Date: Thu, 28 Jun 2007 17:13:13 -0400

Alan Watson posed this excellent question:

> Supposed an implementation uses IEEE double-precision numbers for all
> inexact reals. What should the implementation do when presented with
> 1.1|24? I can think of at least three reasonable options:
>
> (a) Find the IEEE double-precision number that is closest to 1.1. That
> is, treat it as 1.1|53.
>
> (b) Find the binary floating-point number with 24 bits of precision that
> is closest to 1.1 and represent this as an IEEE double-precision number.
> That is, perform a correctly-rounded conversion to 24-bits of precision.
>
> (c) Find the IEEE double-precision number that is closest to 1.1, round
> the result to 24 bits of precision, and represent the result as an IEEE
> double-precision number. That is, potentially, perform double rounding.

Mike Sperber replied:

> I believe it requires (b).

Causing Alan to gasp:

> [F/X: Sharp intake of breath at the implications of this. Sounds of
> someone throwing out David Gay's dtoa.c and reaching for a copy of
> Burger & Dybvig.]

Fortunately, an editor's opinion is not normative.

The current draft says the lexical notation x|p
"represents the best binary floating-point approximation
of x using a p-bit significand." That phrase, and the
other language of the current draft, is not sufficient
to determine whether it would be better to convert that
lexical notation into an even better approximation of x
by using more than p bits, or to limit the accuracy of
the approximation to what can be achieved using p bits
even though more than p bits are available in the actual
representation.

(This recalls the strictfp brouhaha in Java, and Kahan's
opinion that extended precision should be used for
intermediate results when available.)

In my opinion, both (a) and (b) are allowed by the current
draft. If the editors want the draft to require (b), they
will have to revise the draft.

I can't imagine a rationale for requiring (b), however.
After all, whatever requirement we're talking about here
presumably does not apply to systems that don't use binary
floating point, and I can't imagine why the editors would
want to put implementors in the position of declaring that
the arithmetic of their systems, though isomorphic to the
arithmetic of some floating point standard, isn't really
floating point. The current draft already contains too
much silliness of that sort.

Alan suggested this wording:

> "Implementations that represent real number objects internally using
> binary floating-point numbers should represent x|p using a p-bit
> significand if practical, or by a greater precision if a p-bit
> significand is not practical, or by the largest available precision if p
> or more bits of significand are not practical within the implementation.
> Note that even if more than p bits of precision are chosen for the
> internal representation, the value should be the best binary
> floating-point approximation of x using a significand with exactly p
> bits of precision."

I would write "may" instead of "should" there. We really
can't know whether 1.1|24 was

  1. written by a human whose intent was to represent 1.1
      with at least 24 bits of precision

  2. written by a machine to express the single precision
      output of some computation

For situation 1, (a) would be better. For situation 2,
(b) would be better. Finally, when IEEE double precision
(53 bits) is used to represent numbers with only 24 bits
of precision, (c) will give you the same result as (b) more
than 99.9999999% of the time.

Someone across the hall from me says the R6RS doesn't
have to be perfect. If the R6RS were as good as (c),
it would be good enough.

Will
Received on Thu Jun 28 2007 - 17:13:13 UTC