[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
Notes on DVJ's draft...
Here are my notes on the July 10 draft that Dave James has
provided us to bring the draft into conformance with the
IEEE style guide. (You can get a copy from him if you have
not already.)
You will note that the non-purple prose portion of the draft
has gone from 106 pages to 64 pages. As Dave has be diligent
about keeping the text almost word-for-word exactly what it
was before, this is largely due to the use of a smaller font
and more page width devoted to text.
I just spent almost 4 hours going over the old document & the
new one side by side & I can say several things:
(1) Dave has not changed anything of substance that I
could find.
(2) It looks substantially better than before.
(3) This effort obviously involved a lot of work for
which we must thank him.
(4) Given the amount of time it took me to verify all
of the above, you might consider spending to time to
read it so you are familiar with the new text by the
time of the meeting next week.
(5) As any such major rewrite must have, there are a
number of changes/errors/typos/nits that have cropped
up. I detail all that I could find below.
BTW, since I spent the entire evening on this, I got a little
petulant from time to time in my comments. Please chalk it up
to fatigue & not value judgement.
It is a remarkable effort.
Thanks Dave,
Dan
---------------------------------------------------------------
Dave,
Here are my notes on your new draft. As much observations
as criticisms. Not all require changes.
Dan
------------------
Page 1, Sponsor: I thought the formal title of our sponsor
group was the Microprocessor Standards Committee. At least
that's what it says on all the agendas when I attend the
meetings.
Page 1, Abstract: I see no period between the end of the
first sentance "... systems" & the beginning of the next
"Exception ...".
Page 1: Keywords: There should be a comma between "format" &
"interchange". Perhaps also between "floating-point" &
"arithmetic" but I'm less certain about that. Ask David Hough.
Page 4, Participants: I noticed you fixed some of my
alphabetization errors. Good catch. You are missing David
Gustavson & me. My name is Dan Zuras. I know you want to list
me as chairman & that's fine but, at least until Robert's Rules
came to our door, I was also a participant, not just a referee.
Jeff Kidder is the current vice chair. We have no secretary at
the moment. Let's talk about that tomorrow. We have never had
money & so never had the need for a treasurer.
Page 9, 1.1 Scope: You have correctly replaced the scope with
that which was in the PAR. David Hough has requested we change
this & this is reasonable. However, Bob Davis has pointed out
that this is the job of the MSC when we go to re-up the PAR.
Still, Bob will take our suggestion on this I think. Therefore,
I'll put an item on the July agenda that we discuss this. Same
goes for Purpose.
Page 10, 1.6 Annexes: The second list item should read "Annex D,
Annex E, and Annex F:".
Page 11, 2 References: Go ahead & reference the 1985 standard.
There is some debate about whether we are a strict superset or
not so referencing it gives one the information needed in any
case. If your second comment is intended to move the reference
to the C language to annex A, I don't agree. Just because it
is informative does not mean it is not referenced. There is
no such thing as a second class reference. I'm not sure I
understand your 3rd note about footnotes. We should also get
a reference to Mike Cowlishaw's DVD patent & put it in here as
well.
Page 12, 3.1 Conformance levels: The IEEE's wording is fine
here. We use 'should' & 'shall' as they do. We have avoided
the use of 'expected' & 'may'.
Page 12, 3.2 Glossary of terms, 3.2.6 computational operation:
David Hough, I fear we must change this yet again.
Page 12, 3.2 Glossary of terms, 3.2.9 declet: There is a space
in the middle of the first word "An" that should be removed.
Your argument about 'dectet' may be valid but the term 'declet'
is one we inherited from the literature. So we stick with it.
I understand & sympathize with the forward reference criticism
here but how is one to define the term 'declet' without putting
the entire page & a half worth of text in Chapter 5 here? We
could just eliminate the phrase "according to Table 5.5 and 5.6"
if you think that would solve the problem.
Page 12, 3.2 Glossary of terms, 3.2.12 exception: Again we
could eliminate the phrase "(see Clause 9)" which would
eliminate the forward reference at the expense of making them
figure it out. Is this really to be preferred?
Page 13, 3.2 Glossary of terms, 3.2.16 faithfully-rounded
result: See, NOW your being inconsistent. This is a case where
the forward reference was replace with the definition & you
STILL don't like it. Its going to be one way or the other.
You're going to have to live with SOME choice.
Page 13, 3.2 Glossary of terms, 3.2.19 fusedMultiplyAdd:
eliminate "(see 7.5.1)".
Page 13, 3.2 Glossary of terms, 3.2.23 NaN: eliminate references
to 8.2 & 9.2.
Page 14, 3.2 Glossary of terms, 3.2.25 non-computational
operation: To be fixed one more time.
Page 14, 3.2 Glossary of terms, 3.2.26 normal number: eliminate
references to tables 5.3 & 5.7.
Page 14, 3.2 Glossary of terms, 3.2.29 quite operation: Don't
know how you want us to fix this one. You can suggest something.
Page 14, 3.2 Glossary of terms, 3.2.33 signal: eliminate
reference to Clause 9.
Page 14, 3.2 Glossary of terms, 3.2.34 significand: Don't get
so narrow minded Dave. The phrase "may be thought of" is NOT a
use of the word 'may' as the IEEE defines it. I don't think our
scope includes the ability to limit the way people think.
Page 14, 3.2 Glossary of terms, 3.2.35 status flag: eliminate
references to 7.8.4 & 7.8.5.
Page 14, 3.2 Glossary of terms, 3.2.37 trailing significand:
eliminate references to 5.2 & 5.3.
Page 14-15, 3.2 Glossary of terms, 3.2.39 width of an operation:
Of COURSE it means conformance to this standard. What OTHER
standard could it possibly mean?
Page 16, 4 Abbreviations & acronyms: While, in principe this
may be a good idea, Intel doesn't want us to use BID, IBM has
defined DPD, & NaN, qNaN, & sNaN are all defined in the glossary
of terms, as they should be so people can find them when the
need to. I have no trouble with duplicating the NaN definitions
here, if that is what you want.
Page 18, 5.2 Specifications levels, Table 5.1: You might
consider center aligning the middle column of this table. Other
than that its fine.
Page 18, 5.3 Sets of representable entites: These definitions
are virtually the same as existed in 754/1985 with the necessary
generalization to include decimal. They are just fine as is &
where they are.
Page 19, 5.3 Sets of representable entites, Table 5.2: Your
title is fine.
Page 20, 5.4 Binary interchange formats, Figure 5.1: Your
redrawing of this figure is (1) correct, (2) better than before,
& (3) exactly what was originally intended. Good.
Page 20, 5.4 Binary interchange formats, Table 5.3: Your title
is fine here too.
Page 21, 5.5 Decimal interchange format encodings, list item b):
This case only covers 0, 1, & 2. The 3 case is covered further
down. Keep reading.
Page 21, 5.5 Decimal interchange format encodings, Figure 5.2:
You got this redrawing correct as well. You eliminated the note
that 3xJ = p - 1 but that may not be important. We can discuss
it tomorrow.
Page 22, 5.5 Decimal interchange format encodings, Table 5.4:
Your title is fine.
Page 24, 5.6 Non-interchange formats: You eliminated the
emphasis of the word "SHOULD" in the second paragraph. Its a
choice.
Page 24, 5.6 Non-interchange formats, table 5.7: It looks fine.
Page 27, 7.1 Overview, 3rd list, 3rd item: Pending the outcome
of some motions, source array MAY cease to exist. We can
eliminate this case if that happens.
Page 28, 7.3.1 General operations, list item nextDown: Preferred
exponent? Good question. I think the correct answer is min(x,
nextDown(x)). Let's discuss it tomorrow.
Page 29, 7.3.2 logBFormat operations, list item logB: Preferred
exponent? I think the correct answer is 0 (this is an integer
in the unexceptional case). Bring it up tomorrow.
Page 29-30, 7.3.2 logBFormat operations, list item scaledProd:
This guy is still pending motions but even if it stays in I
don't know the correct answer to the preferred exponent.
Page 30, 7.4.1 General operations: Like nextUp & nextDown,
I think the only possible preferred exponent in the non-
exceptional case is min(x, nextAfter(x, y)). But I'm open to
discussion.
Page 31, 7.5.1 Arithmetic operations: Like logB, the preferred
exponent of all convert to integer operations must be 0.
Page 32, 7.5.2 Conversion operations for all formats, last two
items: I have no good answer to the preferred exponent in these
cases. Perhaps Mike does. I have no objection to the name
changes. It DOES seem more consistent. Make a motion to that
effect.
Page 33, 7.7.1 Comparisons: Quite correct. These DO return
booleans. It should be fixed.
Page 34-35, 7.8.2 General operations, list item class: It looks
OK to me.
Page 36, 7.8.6 Operations on individual modes: This is a nit
so forgive me for painting the shed. The adjective 'prevailing'
has the connotation of "the most common among many in extant at
the moment". The adjective we are seeking here is something that
means "of the many possible, the only one in effect at the moment".
Any suggestions from those of you who know English better than I?
Page 39, 7.12 Comparison predicates: David Hough, my
interpretation of the motion that created mixed radix
comparisons is that they should be the ONLY mixed radix compares
not in ADDITION to some less accurate mixed radix compare. On
your second point, I believe the answer is yes but that's not
the way I look at it. Again, my interpretation is that the
comparison 'binaryFP < 0.1' is an operation in which '0.1' is
converted to binary before a binary comparison takes place. To
specify the other possible comparison you must say something
like 'mixedBinaryDecimalLessThan(binaryFP, 0.1)'.
Page 41, 7.13 Conversions between ...: How can a section title
be too long & why must it be shortened?
Page 41, 7.13 Conversions between ...: Have you checked for the
correct cross reference?
Page 42, 7.13.1 External character ..., paragraphs 6 & 7:
Whatever it is that Jim Thomas has to explain here, now is the
time to explain it.
Page 43, 7.13.3 External decimal ..., equations for m & n: You
got them correct.
Page 44, 8.2 Operations with NaNs: Have you checked those
references?
Page 46, 9.1 Overview: ...: David Hough, time to answer this
question.
Page 47-48, 9.4 Overflow: And this one.
Page 48, 9.5 Underflow: And this one.
Page 48, 9.5 Inexact: And this one.
Page 50, Annex B, B.2 Optimization, 3rd list item: Depending
on the outcome of current motions, scaled products, as well.
Page 53, Annex C, Table C.1: Is it REALLY OK to drop the
754/1985 references?
Page 53, Annex C, Table C.1: The use of 1..12 & 1..8 refers to
a previous way of indicating the the 12 quiet & 8 signalling
comparisons. This is not just unclear but obsolete & should be
replaced by their names.
Page 55, Annex D, Table D.1: I have always been troubled by
the inclusion of sinPi, cosPi, & atanPi (functions which seldom
appear anywhere) on this list. It seems to me that their only
justification for existing is that their domain reduction is
easy. And yet, domain reduction is NOT the problem with either
correct or faithful rounding of the circular functions. I also
dislike (for related reasons) the restriction of the domain of
sin & cos to some arbitrarily chosen small subset. So long as
this entire section in informative only we should say that all
transcendentals SHOULD round correctly for their entire domain
& SHALL faithfully round for their entire domain. (Appropriate
sign symmetries, antisymmetries & all possible algebraic limits,
of course.) Anything less is too narrow in both time (our
epoch) & application. End of flame.
Page 57, Annex E, E.4 Precedence: David Hough, another question
to answer now.
After page 64 (the end): You have eliminated the purple prose.
This is fine & what was intended before the June meeting.
However, since the output of this committee is just the text of
the document, we should discuss what happens with our rationale
so it is not lost to history.