[
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