[r6rs-discuss] put-datum, get-datum, equal?, eqv?, and NaNs

From: William D Clinger <will>
Date: Sat, 30 Jun 2007 07:12:46 -0400

Alan Watson wrote:

> > Are you complaining about the rule that says the absence
> > of |p (for an inexact decimal notation) means the same
> > as the presence of |53 ?
>
> Yes. However, it doesn't make any difference on common systems that
> internally use only IEEE double-precision. But this is Scheme and we
> should strive to do better than that.

I see your point. Furthermore, as explained below,
this rule completely screws up the intended lexical
syntax of flonums, even on systems that use double
precision.

That rule should definitely be dropped.

> > Or the rule that says a
> > denormalized double precision number really ought to
> > be printed with an explicit mantissa width?
>
> Where does it say that?

This note in section 4.2.8 of the R5.96RS draft:

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

SRFI 77 listed the following as an issue:

    The x|53 default for the mantissa width
    discriminates against implementations that default
    to unusually good representations, such as IEEE
    extended precision. Are there any such
    implementations? Do we expect such implementations
    in the near future?

That default was only a "should" in SRFI 77, and remains
only a "should" in the R5.96RS draft:

    If x is an external representation of an inexact
    real number object that contains no vertical bar, it
    should be treated as if specified with a mantissa
    width of 53.

I am now quite disturbed by Mike's stated belief [1]
that the R5.96RS draft requires the following behavior
when an implementation reads 1.1|24:

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

Here are Mike's exact words:

    I believe it requires (b). I can't find any
    ambiguous wording on the subject--if you think it's
    ambiguous, please let me know where exactly so I can
    fix it.

If he "fixes" it by requiring (b) and/or strengthening
some of the "should" language to "must", the flonums
library will be endangered. Consider the following
quotations from the R5.96RS draft:

    If x is an external representation of an inexact
    real number object that contains no vertical bar, it
    should be treated as if specified with a mantissa
    width of 53.

    If x is an external representation of an inexact
    real number object and contains no vertical bar and
    no exponent marker other than e, the inexact real
    number object it represents is a flonum (see library
    section on "Flonums"). Some or all of the other
    external representations of inexact real number
    objects may also represent flonums, but that is not
    required by this report.

That means 1.0 "should" be treated the same as 1.0|53,
which means 1.0 is not necessarily a flonum. It would
appear that, in the R5.96RS draft, there is no portable
way for a programmer to write 1.0 as a flonum.

Depending on the exact language of Mike's "fixes", they
might well prevent any implementation from reading any
external representation as a flonum, which would make
the (rnrs flonums (6)) library fairly useless.

I am also freaked by Mike's more recent reply to Alan:

> > Are the editors happy with this additional restriction on the behaviour
> > of eqv? with NaNs?
>
> Yes, but the tightening of the spec of `put-datum' was premature, I
> believe, and needs to be suitably weakened.
Received on Sat Jun 30 2007 - 07:12:46 UTC