Thoughts and comments on P1788/D9.5
Dear P1788 members,
I second what Michel and Vincent already mentioned that P1788 is in good
shape and mainly needs some simple editorial work. Two issues need some
attention thus I bring them to the attention of the whole group so that
you all can chime in while I upload all my comments to the official
site.
Page 63, lines 24 and 25 say:
"For sumAbs and sumSquare, if an Infinity is encountered, $+\infty$
shall be returned. Otherwise, if a NaN is encountered, NaN shall be
returned."
The order in the above text gives precedence to infinity over NaN in an
example such as sumSquare(2, 3, +\infty, NaN)=+\infty and not NaN. I
checked IEEE 754-2008 and found that it has the same order as mentioned
here. This is in contrast to the general direction of IEEE 754-2008
which would have given precedence to NaN if the sumSquare was computed
using the other basic arithmetic operations of 754-2008. Also notice
that according to the current wording of P1788
sumAbs(2, 3, +\infty, NaN)=+\infty
while
sum(2, 3, +\infty, NaN)=NaN.
Is this desired?
The opposite order: "if a NaN is encountered, NaN shall be returned.
Otherwise, if an infinity is encountered, $+\infty$ shall be returned."
gives precedence to NaN. Which order is needed in P1788 applications?
For those in the group who were also part of 754-2008: Was this change
of order intentional in 754-2008 or an oversight? (I personally do not
remember!)
Page 67, lines 6 to 12, for 754-2008 decimal formats, the restriction
d_0 \neq 0 (representation with smallest quantum) is incompatible with
the definition of "decimal number" on page 55 within sub-clause 12.11.2
number literals and its use in all the subclauses of 12.11.
In fact, 12.11 allows a representation such as 0.060?1u = [0.060, 0.061]
to indicate the weight of an object as being about 60 grams measured to
the nearest gram for example. This example conforms to IEEE 754-2008
decimal formats which allow leading and trailing zeros for numbers.
However, sub-clause 13.4.1 says that 0.060 may be represented by the
string 6.0e-2 or 6.e-2 or 6e-2, optionally dropping the trailing zero
and the point, but never by a string with leading zeros. So, as it
currently stands, P1788 accepts leading zeros in input literals but does
not produce them in output literals. Is this desired? What is the
rational?
Furthermore, the dropping of trailing zeros conflates 0.060 and 0.06 as
being the same while obviously 0.060?1 and 0.06?1 are not the same. I
suggest that we put a note with an example as the one here to clarify
the effect of dropping trailing zeros if the output strings are going to
be re-introduced as input strings later.
The rest of my comments follow
-----------
Page vi, lines 5, 7, 13, and 14, several names start with just a first
initial while all the other names have the full first name. Is this
acceptable for IEEE? If not, maybe we can contact those colleagues and
check the proper way to list their names (R. Baker Kearfott, R. Ian
Mcintosh, J. Wolff von Gudenberg, and G. William Walster).
Page vii, line 45, need a reference to the system of Rump
Page ix, line 27, "IEEE 754" should be either "IEEE 754-1985" or "IEEE
754-2008" (or "IEEE 754-1985 and 754-2008").
Page ix, line 30, "and record" should be "and are recorded"
Page ix, line 40, "IEEE 754 double precision numbers" should be "IEEE
754-2008 binary64 numbers"
Page ix, line 41, "that in the the" remove the extra "the"
Page 2, line 5, "IEEE 754" and whenever it occurs should be "IEEE
754-2008"
Page 6, line 3 and footnote, is this footnote acceptable as part of a
standard?
Page 6, after line 10, add definitions for compressed interval and
compressed arithmetic.
Page 10, line 2, "P1788" should be replaced here and wherever it
appears by the final official name of the standard.
Page 10, lines 21 and 22, "The procedure for submitting new flavors to
be included into the standard is described in the Introduction" where
in
the introduction? I cannot find it. Maybe we should change the footnote
to be similar to the footnote on page 19 which refers to the "Comments
on standards" section of the front matter.
Page 15, line 18, "a arithmetic operation" should be "an arithmetic
operation".
Page 15, line 31, "Brouwer Fixed Point Theorem" should have a
reference.
Page 15, line 39, " (i) to (iii) " should be " a) to c) "
Page 17, line 7, "FTIA" should be "FTDIA"
Page 18, line 20, "(ii)" should be "b)"
Page 19, line 21, "each non-standard flavors conforms to ..." : it
seems incorrect to put conformance constraints on the implementation in
parts where it chose to be non-standard, i.e. non-conforming!
Page 21, line 9, "the the number" remove the extra "the"
Page 22, line 30, "one-one" should be "one-to-one"
Page 27, line 9, "case (a))" should be "case a)", i.e. remove the extra
()
Page 28, top line before the table, "Table 10.5" should be "Table 9.1"
Page 28, notes i and j, "the C standard" needs a reference.
Page 30, line 26, "-\infty \leq x \leq +\infty" should be
"-\infty < x < +\infty"
Page 35, line 4, the "Notes" are only informational (as stated in the
footnote on page 10) however this line has a recommendation (it uses
"should"). I suggest we remove the word "Note".
Page 36, after table 10.3, maybe we should add a note explaining some
of the "strange" results of this table. For example if a=empty and b
not
empty then "a is subset of b" and "a is disjoint of b" are both true.
Page 39, line 28, "Sun's interval Fortran" should have a reference.
Page 42, line 4, bad spacing.
Page 44, line 8, "case function" is not defined in the standard.
Page 47, line 23, "three kinds of interval type" should be "... types"
Page 52, line 30, should "componentwise" be written "component wise"?
(Similarly on page 53 line 24 and whenever it occurs.)
Page 53, lines 15 to 17, should this example be typeset in the
specific
style used for examples throughout the text? (Similarly on page 54
lines
6 to 10.)
Page 55, line 8, "the nearest binary64 numbers either" should be "...
numbers on either"
Page 56, line 11, "form (a)) above" refers to form a) of 12.11.2 not
to
the point a) directly above it within 12.11.4. The hyperlink is correct
but the text itself needs clarification.
Page 58, table 12.2, the notation used (*, +, ?, ...) should be
explained to avoid any ambiguity in their interpretation.
Page 62, line 12, "+ oo" should be "+\infty"
Page 63, clause 12.12.10, what happens if T is a bare interval type
only (with no decorated intervals) and a user gives the operation
T-convertType(xdx) on a decorated interval? Maybe we should explicitly
say what happens when convertType is used from decorated to bare or
vice-versa from bare to decorated.
Page 63, lines 24 and 25 say:
"For sumAbs and sumSquare, if an Infinity is encountered, $+\infty$
shall be returned. Otherwise, if a NaN is encountered, NaN shall be
returned."
The order in the above text gives precedence to infinity over NaN in an
example such as sumSquare(2, 3, +\infty, NaN)=+\infty and not NaN. I
checked IEEE 754-2008 and found that it has the same order as mentioned
here. This is in contrast to the general direction of IEEE 754-2008
which would have given precedence to NaN if the sumSquare was computed
using the other basic arithmetic operations of 754-2008. Also notice
that according to the current wording of P1788
sumAbs(2, 3, +\infty, NaN)=+\infty
while
sum(2, 3, +\infty, NaN)=NaN.
Is this desired?
The opposite order: "if a NaN is encountered, NaN shall be returned.
Otherwise, if an infinity is encountered, $+\infty$ shall be returned."
gives precedence to NaN. Which order is needed in P1788 applications?
For those in the group who were also part of 754-2008: Was this change
of order intentional in 754-2008 or an oversight? (I personally do not
remember!)
Page 67, lines 6 to 12, for 754-2008 decimal formats, the restriction
d_0 \neq 0 (representation with smallest quantum) is incompatible with
the definition of "decimal number" on page 55 within sub-clause 12.11.2
number literals and its use in all the sub-clauses of 12.11.
In fact, 12.11 allows a representation such as 0.060?1u = [0.060,
0.061]
to indicate the weight of an object as being about 60 grams measured to
the nearest gram for example. This example conforms to IEEE 754-2008
decimal formats which allow leading and trailing zeros for numbers.
However, sub-clause 13.4.1 says that 0.060 may be represented by the
string 6.0e-2 or 6.e-2 or 6e-2, optionally dropping the trailing zero
and the point, but never by a string with leading zeros. So, as it
currently stands, P1788 accepts leading zeros in input literals but
does
not produce them in output literals. Is this desired? What is the
rational?
Furthermore, the dropping of trailing zeros conflates 0.060 and 0.06 as
being the same while obviously 0.060?1 and 0.06?1 are not the same. I
suggest that we put a note with an example as the one here to clarify
the effect of dropping trailing zeros if the output strings are going
to
be re-introduced as input strings later.
Page 68, line 34, "in the notation above" which notation? where was it
mentioned?
Page 69, line 23, "may potentially use cohort information" should be
"may potentially use cohort information in decimal formats (refer to
IEEE 754-2008)"
Page 73, line 7, should it be 0 not in d instead of b?
Page 74, line 5, the `.' should be at the end of the previous line to
terminate equation 31.
-----------
I hope this is enough food for thought for everyone :)
--
Dr. Hossam A. H. Fahmy
Associate Professor
Electronics and Communications Engineering
Cairo University
Egypt
http://eece.cu.edu.eg/~hfahmy/