[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

My P754 1.8.0 ballot



Overall comment:  I consider my suggestions to be corrections to changes
introduced between 1.7.0 and 1.8.0.  Most of those changes were for the
better, but two of them were, I think, simple mistakes.

The idea is not to introduce any normative changes, given that 1.7.0 had
achieved substantial agreement already.  In that sense I consider a fix
that reverts to 1.7.0 a non-normative change, even though it may disagree
with one possible interpretation of what 1.8.0 appeared to declare.

Technically, the change is technical, but I classify it as Editorial
because I'm treating it as a correction of an unintended text change.

For my second point, restoring radix dependance to preferredWidthFormat,
I'm trying to stay minimal.  Reversion to the 1.7.0 text might be another
option, but presumably there were comments that led to the change, and I
don't want those to be ignored altogether.

                             *---------*

I vote APPROVE, with the following comments:

Editorial  P29  #5.4.3  L37

    I suspect the change from "shall" to "should" (relative to all
    earlier drafts) was a mistaken attempt to resolve an apparent
    inconsistency with an existing "should" in 5.12.3 -- however,
    the latter applied to language standards, not to conforming
    implementations.  Instead, the change introduced a genuine
    inconsistency with 5.12 (page 37 line 24), which still has
    "shall" for providing conversions to and from hexadecimal
    strings for binary floating-point formats.

    Change "should" back to "shall" to restore what has commonly
    been agreed on (and leave 5.12 and 5.12.3 alone).

Technical  P56  #10.3  L20

     Draft 1.7.0 clearly had per-radix preferredWidth attributes,
     though it was not at all clear how that would be specified.
     That issue is however language-private, and 754 need not go
     into it -- but the concept matters.  Whether we have named
     attributes for each format, or one attribute with a name
     that denotes a format or language type, the same name can
     most likely not be meaningful for both binary and decimal;
     even the width might be different for good reasons, e.g.
     64-bit for binary but 128-bit for decimal.  At this point
     we cannot go into more details, but I think readers will be
     able to figure it out, so I'm looking for minimal change.

     Change "should define" to "should define (for each radix)".

Technical  P56  #10.3  L16

     Same issue as comment #2, but for preferredWidthNone.  This
     case is however less critical, as a global preferredWidthNone
     makes perfectly good sense (unlike preferredWidthFormat).  We
     could leave this one alone, or at least permit radix dependence.

     Change "should define" to "should define (possibly for each radix)".


Michel.
Sent: 2008-04-11 21:34:18 UTC


754 | revision | FAQ | references | list archive