Thread Links | Date Links | ||||
---|---|---|---|---|---|
Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
P1788 As our deadline is coming swiftly, I take the liberty of circulating this version of the text (labeled as Draft 8.1) without the permission of the other editors, as the basis for A vote on the Level 2 text, Clause 12. I hope they will approve. I think it is sufficiently mature that the structure of Clauses 1 through 12 (Level 2) and 13 (I/O) will not change. Shortly, I expect an essentially finalised Clause 14 (Level 3) plus informative material nicely organised into Annexes. The result will be circulated as Draft 9.0. I propose, subject to the Chair's approval, to split Level 2 into these four separate motions, to be votes on ACTUAL TEXT, all running SIMULTANEOUSLY. Motion Subclauses Pages of V8.1 M0054? 12.1-12.9, pp45-49, about 5 pages Introductory stuff: number formats, interval types, versions of operations, ... M0055? 12.10, pp49-51, about 2 pages plus 12.13 p59, about 0.3 page Accuracy requirements for operations; and recommended operations M0056? 12.12 intro plus 12.12.1-12.12.7 pp53-56, about 3 pages Required operations, part 1 M0057? 12.12.8-12.12.13 pp56-59, about 4 pages Required operations, part 2 (including constructors, also reduction operations) (Note: 12.11 "Interval literals" is the subject of Motion M0051, under vote now.) Discussion among the editors (me, C. Keil, G. Melquiond, D. Nazhedin, N. Nedialkov, J. W. von Gudenberg) aided by M. Hack, V. Lefevre, has been intense and led to many recent improvements. But ATTENTIVE READING is still much needed! Text that was clear to the writer may be unclear to you: point it out! And only last week, Dmitry Nazhedin found an inconsistency where, when tidying up text on decorated operations, I had missed an item on Boolean functions of intervals. That last was a problem with *structure*, but we also have some *technical* issues. I list some that affect these Level 2 Motions: - Are the notions of "providing" versus "supporting" something defined clearly enough? Especially relevant to number formats, since these in a sense are a channel of communication between the interval world and the "rest of the system" (as input to numsToInterval(), and as output from functions like mid()). A related issue: - Have we the most appropriate spec, 12.12.9, for what "Numeric functions of intervals" should be provided? It says "...shall provide a T-version of each numeric function ... for each supported bare interval type T, giving a result in a supported number format F that should be compatible with T ..." - Is the "short-cut" interval extension of the case(c,g,h) function the most useful one for this standard? Is its decorated version correct? - Should taking the intervalPart of NaI generate an exception? (It may be regarded as a failed call of a bare interval constructor.) - For decorated intervals XX, YY we have (12.12.10) * equal(XX,YY) which ignores the decorations, * decoratedEqual(XX,YY) which takes the decorations into account, (but both behave in a special way on NaI's). Is this the best solution? How to get most reliable proofreading of these pages? Maybe, each person choose one of these motions at random, as their target for careful study. Any better ideas welcomed. Regards John Pryce
Attachment:
20131025P1788_MAIN.pdf
Description: Adobe PDF document