[r6rs-discuss] Confusion over |p

From: William D Clinger <will>
Date: Sat, 30 Jun 2007 21:35:47 -0400

Alan Watson wrote:
> I think you want to say "binary mantissa with a width of 53 or more".

Okay, let's try again:

    If x is an external representation of an inexact
    real number object that contains no vertical bar
    and no exponent marker, then implementations that
    use binary floating point representations for
    inexact reals should compute the numerical value
    of x as though it had a binary mantissa width of
    53 or more.

> Will someone please explain: (a) what problem |p is solving

The |p notation is a replacement for the # notation
that the R5RS used for nonsignificant digits. One
of the things we learned from this process is that
many Scheme programmers, perhaps even a majority,
and apparently including several implementors, were
interpreting # to mean 5 rather than 0. That doesn't
work, because it makes the numerical value depend upon
the number of trailing #s, which are supposed to be
insignificant.

We also learned that hardly anyone is using the R5RS
notation. I could list a dozen extensions to R5RS
lexical syntax that are in more widespread use, yet
are not allowed by the draft R6RS.

> 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.

Mike doesn't want to drop the implicit mantissa
altogether, because he fears some unspecified
consequences. After all, there might be some
interaction with library versions.

> > Note: When the underlying floating-point
> > representation is IEEE double precision, the |p
> > suffix should not always be omitted: Denormalized
> > floating-point representations have diminished
> > precision, and therefore their external
> > representation should carry a |p suffix with the
> > actual width of the significand.
> >
> > Fortunately, that is only a "should".
>
> I believe this means "the programmer should write subnormals in their
> program and in data using explicit precisions" not "number->string and
> its friends should by default add an appropriate |p to subnormals".

I think Mike intends for it to mean implementations
should print denormalized numbers with an explicit
|p suffix. This is another example of the general
confusion between programmers' and implementors'
responsibilities that Mike has been trying to
straighten out. In all fairness, he has made some
progress.

> This requirement on the programmer (along with the effective promotion
> of 1.1f0 to 1.1f0|53) strikes me as unreasonable and unjustified.

The recommendation about denormalized numbers is
only a "should", and doesn't do a lot of harm
even if programmers or implementors follow the
recommendation, so we could just ignore it.

The promotion of 1.1f0 to 1.1f0|53 would be a more
serious problem for portability, even as a "should",
because higher quality systems would just ignore the
"should", while implementors who take the R6RS more
seriously would probably implement it.

> However, I don't think we can then simply write
>
> (string-append (number->string x) "|" (number->string p))
>
> as this need not be the shortest decimal representation that gives x
> when read back.

Right. I realized that after my post, but didn't
want to annoy people with yet another correction.
The algorithms you described would be better anyway.

Will
Received on Sat Jun 30 2007 - 21:35:47 UTC