[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
Comments on draft 1.1.5 (Aug15) for Aug17 style review
The headers mention 1.1.5 but still say "August 12" -- should be "15".
Page 13, glossary entry 3.2.13 exponent, end:
...where p is the significand length.
How about: ...where p is the precision.
Later, add glossary entry for "precision":
3.2.27 precision: The length of the significand in digits or bits.
Perhaps we also need a definition of "digit", which has the
usual meaning for decimal floating point, but which means
"bit" for binary floating-point -- then the "or bits" could
be omitted from the definition of "precision".
Actually, I see that the document is fairly consistent in
applying "bit" to encodings only, so perhaps "digit" is
sufficient -- but it should still have a glossary entry.
This could say that the digit values are 0,1 for binary
and 0...9 for decimal, and perhaps avoid "bit".
Page 16, glossary entry 3.2.29 width of an operation: Here is an
opportunity to apply "supported format" instead of "one of
the formats provided by an implementation in conformance
to this standard."
Page 15 clause 4: Have we started collecting acronyms to be listed here?
Page 17, 5.2, immediately below table 1: There are at least two distinct
notions of "extended reals" in mathematics, the "affine" and
the "projective". Should we be precise and say, at least on
this line, "affine extended reals"? (25 years ago both were
under consideration; Prof. Kahan can tell you the history of
how affine came to be selected as the only one to be supported.)
Perhaps this is ok; "affine" is used in 8.1 Infinity Arithmetic.
Page 17, 5.2, 1st bullet: instead of simply "(see 5.1)",
say: (b is the radix; see 5.1)
Alternatively, say "(see 5.3)" -- perhaps that was the intent.
Page 24, bottom, new text on rounding, 1st sentence, last word "result"
should be singular (each operation has only one result that
is subject to rounding).
Page 28, top, nextAfter(): Should be
sourceFormat nextAfter(source, source)
now that the operation is homogeneous. (I had not noticed
last week because of the unfortunate page break in 1.1.4)
Same item, 2nd bullet: If x == = y (too many = signs)
Incidentally, is it reasonable to use C syntax here,
instead of the usual mathematical comparator "="?
After all, not-equal uses slashed = and not !=.
The font should include a mathematical "=" which is indeed
slighly longer (like em-dash) than ordinary "=" (n-dash-size).
Page 29, 7.4.1, near bottom: change "See 7.9" to "See 7.8" -- unless
the order of clauses 7.8 and 7.9 is reversed to follow the
order in which the operations were introduced summarily (in
which case the references to 7.9 in 7.3.1 on page 27 have to
be updated).
Page 30, last item of 7.4.1, formatOf-convert(int), line 1:
remove "between"
Page 31, new text in 7.5.1: At least for the first instance, I would
acknowledge that there are other assignment operators than
those of C: "Often written y = x, or y := x."
For abs(x), are there languages that use "=" for assignment
and "|" for absolute value? In mathematical publications "="
is almost never an assignment operator, it is almost always
a comparator. So here ":=" would be more appropriate, and
I suspect "often" should be "sometimes" here.
Page 31, end of 7.5.2: I would also define "decimalType", and be a
bit more helpful in avoiding confusion, without (I think)
violating the gag rules surrounding DPD/BID:
... where decimalEncodingType is a language-defined type
for storing decimal-encoded decimal floating-point numbers,
binaryEncodingType is a language-defined type for storing
binary-encoded decimal floating-point numbers, and decimalType
is the standard type of the given decimal floating-point format.
Page 32, 7.6.2, signalException(), last paragraph, 2nd sentence (of 3):
I would insert, before "then it signals", the following:
"and these cannot be signalled concurrently,"
In some implementations they can, e.g. there is a generic
handler that is told which group of exceptions is being
signalled (which is different from which flags have been
or will be raised). Since non-default exception handling
has not been defined normatively, this possibility should
be left open.
Page 34, 7.7.3, sameQuantum(), line 1 of paragraph after bullet:
remove "q," -- or at least the comma. Alternatively,
since in other contexts Q(x) and Q(y) are used, say
"if Q(x) = Q(y)".
Page 36, 7.8, line 2 of 1st para, editorial question: "supported"
is now in the glossary; "provided" and "implemented" are
probably synonyms and have their ordinary meaning -- unless
somebody draws a distinction for implemented-but-not-documented.
These operations should also all be "intFormatOf-..." and not
"formatOf-...", and the italic word "format" should be replaced
with an italic "intFormat" in the text.
(As mentioned earlier, for page 29 7.4.1, would it not be better to switch
the order of 7.8 and 7.9 to follow the order of 7.3 and 7.4 above?)
Page 42, 7.12.3, external decimal.... line 2 of 1st paragraph:
change <= to >= (It should be \mu >= (m+3).
I don't know when this error was introduced; I missed it on
earlier readings, but it is correct in Dave James' versions.
It was also correct in June 2006.
Page 42, 7.12.3, external decimal.... line 4 of 1st paragraph:
...all integers of the form M*10**N where integer
|{bold m}| <= 10**\mu-1 and integer |{bold n}| <= \eta.
This is old nonsense which I should have noticed months
ago, but now made worse by confusions between several
different letters M, introduced when Dave James started
repairing font issues. The fonts were consistent (but
perhaps unusual) in 5.13.3 on page 82 of draft D0.18.8
of 26 June 2006.
The original nonsense is easy to fix: "all decimal integers
of the form" should be "all decimal numbers of the form".
Actually, that's not enough: another fix is needed when
\mu is very large, because that shifts the relevant range
for the exponent N relative to \eta.
The bold m and n should be the capital M and N here, and it
is indeed M and N that should be integers.
Bold m and n are what used to be script capitals.
Here is a corrected first paragraph, using *c* to denote
character c in bold font:
Conversion parameters *m* and *n* are specified below
according to the widest internal format supported in
a radix. For each supported radix, an implementation
shall define integer \mu >= (*m* + 3) and integer
\eta >= *n*, and shall provide conversions between all
interchange and non-interchange formats and at least
one external character sequence format that represents
all decimal numbers of the form M*10**N where integer
M is such that |M| <= 10**\mu-1 and integer N is such
that 3 + *m* - \eta <= N + \mu <= 3 + *m* + \eta.
It might be easier to state the intent: values in the range
10**-\eta to 10**+\eta with up to \mu digits should be
representable -- or is it 10**-\eta to 10**(\eta + *m* + 3)?
You see, the effective exponent depends on both an explicitly
given exponent (as in 1.2e-3) and the position of the decimal
point (as in 0.0012). The exponent due to the decimal point
can vary enormously, bounded only by the size of the address
space holding the string -- even when \mu is small, because
leading and trailing zeros do not contribute to the number of
significant digits.
I can demonstrate that the original text that introduced \eta
is inconsistent. Suppose the widest implemented format has
an emax of 9999, then \eta could be as small as 9999. Then,
regardless of \mu, small normal numbers with a minimal
exponent could be restricted to one significant digit and
still satisfy the the bounds on N. So all this gibberish
with nested logarithms is a waste of fine print!
I'm not entirely sure what to do about this. The standard
formats are ok (after my correction), because their exponent
ranges are not close to powers of ten. But IBM Fortran has an
extended-exponent range base-16 format whose decimal exponent
range is -9865 to +9861, awfully close to 9999; luckily the
precision is only 35 digits. If it were 135 digits there would
be trouble!
I suppose it would take a motion to reword this in a way that exhibits
the original intent (which I'll have to guess, since that text was
present long before I joined the committee), so for now let's just
fix the obvious problems.
Page 43, 8.1 Infinity arithmetic, last item:
nextAfter(max normal, -inf) does not signal overflow,
nextAfter(-max normal, -inf) signals overflow
How shall we rephrase this? Overflow if signs match?
(Btw, I'm not sure I understand why nextAfter would ever signal
Inexact, though it might be allowed to do so to accomodate
environments where overflow or underflow cannot be signalled
without inexact. I suspect this is a can of worms.)
Page 43, 8.2.1, Binary encoding of NaN, 2nd paragraph: 5.4.0 -> 5.4
Page 44, 8.2.2, Decimal encoding of NaN, 1st paragraph: 5.5.0 -> 5.5
Page 44, 8.2.3 NaN propagation, last paragraph is incorrect, because
it implies that a non-canonical combination field for DFP would
have to be preserved. I wonder why the trailing significand was
mentioned explicitly. All BFP NaNs are canonical, so somebody
must have thought DFP NaNs could carry information in the exponent
continuation field, or the unused bits of the combination field.
This should be fixed to say that canonical qNaN must survive a
round-trip through a wider same-radix format -- but technically
this is a normative change, or rather, this paragraph conflicts
with 5.5 as revised last week.
Page 44, 8.3 The sign bit, 2nd paragraph line 1, there is a crossed-out
"t" in the 2nd "the" on the line.
Enough for now. I stopped at the end of chapter 8, page 44.
Michel.
Sent: 2006-08-16 22:00:19 UTC