[r6rs-discuss] Confusion over |p

From: Alan Watson <alan>
Date: Mon, 02 Jul 2007 12:25:39 -0500

William D Clinger wrote:
> The |p notation is a replacement for the # notation
> that the R5RS used for nonsignificant digits.

Thank you for explaining this.

I can accept the explicit |p notation.

That said, I think it is naive, because real-world uncertainties are
typically modelled by intervals and probability distributions rather
than being specified as a significand length, and I think implementing
it correctly will distract implementors from other more worthwhile
improvements. Furthermore, it seems bizarre to specify the uncertainty
in a decimal number by reference to its binary approximation. I think I
will keep this week's pocket money.

>> and (b) what
>> problem the implicit mantissa width on unadorned inexact reals is solving.
>
> I don't think the implicit mantissa solves any
> problems. It just creates problems.

Yes.

(a) What is special, fundamentally, about 53? Is it not just an accident
of current implementations of Scheme?

(b) The implicit |p makes it cumbersome for me to ask for the inexact
number that is closest to a specific exact number. For example, the
speed of light in a vacuum is an exact number: it is 2.99792458e8 m/s by
definition (and this, along with the definition of the second,
effectively defines the meter). How do I express the speed of light in a
Scheme program? I could just write #e2.99792458e8 and be done with it.
However, if I want the flonum or the inexact number that is closest to
the speed of light, I have to write:

   (real->flonum #e2.99792458e8)
   (inexact #e2.99792458e8)

I cannot just write 2.99792458e8, because this implies only perhaps 53
bits of precision. (I just hope compilers will learn to fold constants!)

(c) Will solved one problem, though, when he specified that
implementations should use 53 or more bits rather than exactly 53.
Consider two implementations: A and B. Both use IEEE double-precision
internally for inexact reals. When presented with a number without an
explicit precision, implementation A rounds to 53 bits and then to IEEE
double-precision. Therefore, implementation A will perform double
rounding on subnormals. In the same circumstance, implementation B
rounds first to a nominally infinite number of bits and then to IEEE
double-precision. Therefore, implementation B effectively performs a
correctly-rounded conversion of the decimal number, even if it is
subnormal. So, Will's modification allows an implementation to ignore
the implicit precision provided it represents inexact reals using only
one type of binary floating-point representation. This is good news, but
it will tend to discourage implementors from supporting more than one
floating-point representation, which is unfortunate.

> Mike doesn't want to drop the implicit mantissa
> altogether, because he fears some unspecified
> consequences.

Mike, I be very grateful to hear your opinion on the implicit |p.
Especially since the current adoption candidate allows the p in the
implicit p to be between 53 and infinity and to vary from datum to datum
  and, as I have explained above, can be interpreted in such a way that
it has no effect on common implementations.

Regards,

Alan
Received on Mon Jul 02 2007 - 13:25:39 UTC