From willemw@komp.ace.nl Thu Oct 5 12:09:33 1995 Received: from komp.ace.nl (komp.ace.nl [193.78.104.90]) by dkuug.dk (8.6.12/8.6.12) with SMTP id MAA27318 for ; Thu, 5 Oct 1995 12:09:33 +0100 Received: by komp.ace.nl with SMTP id AA31484 (1.10/2.17); Thu, 5 Oct 95 12:01:19 +0200 (MET) To: sc22wg11@dkuug.dk Subject: WG11/N419: report on LIA-2 discussion (part 2 of 2) Reply-To: Willem Wakker Date: Thu, 05 Oct 95 12:01:18 N Message-Id: <31482.812887278@komp> From: Willem Wakker ISO/IEC JTC1 SC22 WG11 N419, part 2 of 2 Start addressing technical issues in LIA-2 draft: Issue 1) Should we retain clause 2.1? Editor suggests removal. Karlsson suggests "as close as possible to LIA-1", with specific text. Meek: This section plays an important role. It insures against unscrupulous conformance claims. It needs to be strengthened, not removed. This draft is a mish-mash, the original draft from last year covered many more cases. Scowen: (From marked up copy) Prefers "conformity to the whole" changed to "conforms", and "conforms" changed to "partially conforms". Wakker: Cannot prevent vendors from making conformance claims. Meek: Rationale of clause 2.1 is to insure that claims of conformity are precise and not exaggerated. Wakker: Doesn't see how clause 2.1 helps this problem. Lozier: Requests clarification of the term "with additional procedures". What about libraries that support multiple data types? What about libraries with additional, unrelated procedures? What about libraries with faster, non-conforming versions of procedures that also contain slower, conforming versions of the same procedures? What about aliases of supported procedure names? Harris: Current wording seems to be a "grudging" compromise between extreme views. Long additional general discussion with no new points raised General consensus: Do not change clause 2.1 Tuesday, 26-Sep-1995 Issue 2) Scowen: Suggests moving last paragraph of clause 4.1 to the end of clause 1. Rationale: This is a good statement of the scope of LIA-2. Harris: Why these specific functions? The purpose of this paragraph is to define the terminology used in the "definition" portions of the main body of the document. Meek: Clarification of Scowen's comment - This paragraph is not discussing symbols used in LIA-2. Wakker: Proposes separate section to cover this topic, as informative text. Suggests leaving the decision to the editor, but not moving it to clause 1. Meek: It can indeed be construed as a scope statement, depending on how it is phrased. Harris: Suggests this topic is more appropriate in the first portion of clause 5.2. Consensus: Doesn't belong where it is now. Does belong someplace in LIA-2 Good arguments for several other places Editor, use best judgement for where to place Issue 3) Scowen: Suggests clause 2 needs to be updated to reflect the new requirements in new clause 6. Rationale: Documentation requirements should be listed directly in the conformity clause. Harris: LIA-1 sets the precedent for a separate section of documentation requirements not listed in the conformance section. Meek: Suggests specifically referencing section 6 requirements for each function individually. Also suggests that in intro to section 6, refer back to section 2. Harris: No benefit in mentioning documentation with each function Consensus: drop issue Issue 4) Editor's issue in A.4.1 - Remove duplication of the normative sections of LIA-1 text, leave only references to LIA-1, including those in Annex A. Meek: Prefers to leave LIA-2 as is - for reader convenience, and so LIA-2 can stand on its own. Harris: agree Wakker: Suggests moving copies of LIA-1 normative text in clause 4.1 to (non-normative) A.4.1 and replacing with references to LIA-1. Add "ulp" discussion to A.4.1. Harris,Meek: agree Issue 5) Scowen: Clause 4.1 Assertion in first sentence of second paragraph is not true (-0, +infinity, -infinity). Also major bone of contention in Karlsson's summary comment. Meek: Keep this symbolic use, it doesn't confuse anyone. Also, using different terminology for these items would confuse users of IEC 559, where this is the accepted terminology for these symbolic values. Suggest: add "except the use of the symbols '-', '+', and 'infinity-symbol' when referring to symbolic values defined by IEC 559" to the end of the offending sentence. Harris: agree General agreement. Issue 6) Rabin: Clause 4.1, end of first paragraph. "Note that Z is-a-subset-of R is-a-subset-of C." Is C ever used in LIA-2? If not, remove " is-a-subset-of C" from the sentence. Is this sentence useful? Harris: As far as I know, LIA-2 doesn't use "C". (ed. This is from LIA-1, editors suggest leaving alone) Harris: Yes, Z subset R is used in the conversion section, says that the conversions are possible. Issue 7) Scowen: Confusing, multiple definitions/uses of floor and ceiling symbols at top and middle of p. 5. Clarify usage. Issue 8) Lozier: Symbols "I" and "F" not defined at all here in LIA-2. Meek: Suggest treat as in issue 4) above. General agreement. Issue 9) Scowen: Suggests we use different words for "predicate". Lozier: Suggests "relational operator" instead. Meek: accepts Issue 10) Scowen: Suggests that SC22 secretariat will request replacement of the terminology "Part 1 of ISO/IEC 10967" by "ISO/IEC 10967-1" everywhere in LIA-2. Barkmeyer: Alternatively - define "LIA-1" as "ISO/IEC 10967-1" and use "LIA-1" as appropriate, within the text of LIA-2. General agreement. Issue 11) Comments on Clause 4.2, Scowen and others: a) Number the definitions, for ease of reference in comments on LIA-2 b) In "continuation value", make parenthetical comment into a note c) ditto, 2nd sentence of "rounding" d) use of "note that" in "rounding function" - should it be a note? Lozier: suggests making usage of parentheses, "note that"s, and references consistent within section 4.2. e) remove one "operation", put it in the proper lexicographic order and spell "user" properly. f) in "round toward zero", change "the one nearest 0" to "the value nearer 0" g) in "shall" and "should", remove "quoted from [2]" h) in "mathematical function", should be a mapping, not a "value" Issue 12) Wakker: Now that the title is changed, we need to make the changes to the term "mathematical procedure" within the text of LIA-2 that were agreed at the last meeting of WG11. New term is "numerical function". Also, take account of this change in 4.2, i.e. replace the definition of "mathematical procedure" with "numerical function" and move the definition to precede "operation". Issue 13) Scowen: Clause 5: Remove "typical" in 2 places in 2nd paragraph. Wakker: Also link the 2 sentences. General agreement. Issue 14) Scowen: Clause 5.x: 2nd word. Change "part" to "clause", since "part" is a reserved word (LIA parts 1, 2, and 3). Several other possibilities discussed. General agreement on: Use "component" instead of "part" in all places in clause 5. Issue 15) Meek: Clause 5.1: Suggests that a sentence be added to say that the input space for IEC 559 extensions is extended to include the symbolic values. Issue 16) Scowen: Clause 5.1: Observes that there is lots of duplication between the definition of "signature" in clause 4.2 and the note in clause 5.1. Barkmeyer and Meek: Suggest removing the text of the definition starting with "The signature . . ." and using it to replace the note in 5.1. General agreement. Issue 17) Scowen: Clause 5.2: Objects to the quotations used around "approximate". Suggests that it be moved to section 4.2 and simply used. General: Desire to clarify. Lots of discussion and several different suggestions. Observation that "approximate" is used as both a verb and an adjective, and is not clear which is meant when the word is used alone. Rabin: Suggests introduction of a notation, e.g. "~" instead Lozier: Disagrees, the usage is plain to readers. Barkmeyer: OK, just remove the quotes. Wakker suggests replacing the terminology: "An "approximate" definition takes the form . . . This is equivalent to the following requirements: . . ." with "If this definition takes the form . . . then the following requirements hold: . . ." General agreement. Wakker also suggests checking that other uses of "approximate" are used consistently. Issue 18) Karlsson: Clause 5.2: Use the suffix "PROC" as a prototype, not an example. Others: Agree. (ed. I was not really clear on which usages this comment applied to.) Issue 19) Scowen: Clause 5.2 c): Replace "a running program . . ." with "a program . . . during execution" General agreement. Issue 20) Scowen: Clause 5.3: remove: "a number of" replace: "An axiom is required to" with "An axiom shall" replace: "Axioms hold" with "Axioms shall apply" General agreement. Issue 21) Rabin: Clause 5.4, 5.6: In the body of LIA-2, the "(value)" notation is used to indicated continuation values, but this notation is not explained. These sections are the natural places for such an explanation. General agreement. Issue 22) Scowen: Clause 5.6: Notice that the first sentence is strictly wrong, -0, +infinity and -infinity are not floating point operands but symbolic values. Suggests: "If these continuation values are used as input operands..." or something like that. General agreement. Issue 23) Scowen: Clause 5.6: Questions use of passive voice in the 2nd to last sentence. Consensus: don't care. Issue 24) Rabin: Clause 5.7: Note 2. Reword. Implementations may produce or store NaNs, but standards never do. Also, remove reference to LIA-1. General agreement. Issue 25) Scowen: Clause 5.9: Change "convenience" to "brevity". General agreement. Issue 26) Rabin?: Clause 6: Note that requirements c and d apply only to "approximate" type procedures. General agreement. Issue 27) Wakker: Clause 6: Suggest renumbering 2nd a-d as h-k General agreement. Issue 28) Editor's Note: Clause 6: Documentation requirements for continuation values? Rabin: Yes, so users can tell if software is behaving as specified. See 5.8 - continuation values are implementation defined. General agreement. Issue 29) Rabin: Clause 6 g): Need reference back to LIA-1 (and perhaps an explanation in LIA-2) for "notification by "recording of indicators"". Also need reference and explanation for the concept of "immediate continuation". General agreement. Issue 30) Scowen: Clauses 7 to 19: Should we move the "extensions" sections to an informative annex, since these are not required? General: No, these are required for IEC 559 conforming implementations. Issue 31) Editor's proposal: Use "approximate" notation for SQRT_F, with .5 ulp error bound? General agreement. Issue 32) Scowen: Clause 8.3: Change "+1" to "1" General agreement. Issue 33) Clauses 8 and 9: See editor's draft text for new functions EXPM1_F and LNIP_F. These functions can achieve more precise results than compositions of existing functions for important input values and exist in many modern math libraries. Suggested at previous meetings. Meek: Now that text exists, it would be easier to add them now and delete later than vice versa. Meek: Do they give results worse than compositions using standard EXP and LN functions for values outside these "improved" ranges? If so, then state this in a note. Meek: In the note under EXPM1_F, change "one" to "1". Wakker: Adding these functions makes it more difficult to "conform to the whole". :-) Rabin: These are useful especially for interest rate calculations, suggest saying this in the rationale. Kakehi: Difficult to achieve these accurate results in other ways. Consensus: Include these as clauses 8.6 and 9.3. Issue 34) Karlsson: Clause 8.2: What happens for POW_FF(+infinity,y) where 0 < y < 1? Wakker: how about "undefined"? Wakker: Let editor decide? Consensus: agreed. Issue 35) Scowen: behavior for LN_F(+infinity)? General: "undefined"? Does any other standard have requirements for this? Rabin: Is it omitted on purpose? General: Need common treatment for 8.2 and 9.1. What does it mean if a case is omitted? Either supply all missing cases, or discuss the meaning of omitted cases in Clause 5 and the rationale. Issue 36) Scowen: Clause 9.1, 9.2: Suggests "undefined" instead of "pole" for LN_F(-0) and LOG_FF(-0, b) where b=<0. (ed. no resolution recorded in my notes) Issue 37) Kakehi: Clause 9.2: Is -infinity < 0? This may be obvious, but it is assumed and unstated. General: agreed, need to state explicitly. Check for other instances. Issue 38) Kakehi: Clause 9.2: Axioms involving "b" need to be qualified with "b > 0". General: agreed. Issue 39) Editor: Clauses 10 and 11: Proposal to limit the accuracy required for two-argument trig functions. Proposal hand carried to the meeting reads as follows: Yet Another Proposal for Changes to LIA-2: Mary Payne, September 20, 1995 Change the accuracy requirement in clauses 10.2, 10.4, 10.6, 10.8, 10.10, and 10.12 so that they apply only if the argument u has an integral value of 1, 360, 400, or 1000, corresponding to the angle measured in revolutions, degrees, grades, and mils, respectively. To implement this change, add the following paragraph to clause 10: Let T be the set of values 1, 360, 400, 1000. Then change clauses 10.2, 10.4, 10.6, 10.8, 10.10, and 10.12 as follows: 1. Replace the word "arbitrary" in the title by "engineering." 2. In the error_limit line of the specification, add "if u in T." This means that LIA-2 provides no accuracy requirements for the trigonometric functions with angles measured in units other than those contained in T. An implementation may, of course, choose to follow the LIA-2 accuracy requirement for other values of u. This proposal is partly motivated by Kent's discussion of potential problems for tiny values of u. I believe that this proposal is probably consistent with the intent of the Ada committee. General discussion of the proposal and its implications Rabin: Suggests limiting to u>1 instead. Others: That seems arbitrary. Lozier: Why not split into several specific functions, one for each of the common units? Others: No, we tried that before and had several objections. Meek: Supports the proposal Rabin: Agree, seems like the shortest path to a good goal Wakker: Supports the proposal Kakehi: Supports. General agreement. Wakker: Suggests that we invite comments on this issue during the review periods. His term is "invite specific guidance on this topic". Kakehi: Can we reduce it to one case? Others: Not obviously and still keep all the benefits. Issue 40) Editor and Karlsson suggest removing the max_arg_PROC and arg_too_big concepts. This would simplify several portions of LIA-2, and implementors need to do something special in large argument cases anyway. Harris: Disagrees with the proposal. Use of very large argument may be unintended and often indicates an ill-designed application. Notification is the most appropriate action in these cases, for safety. Also, there are no obvious applications that can really depend on such behavior today or in the forseeable future. Lozier: This proposal doesn't represent standard practice. LIA-2 shouldn't force other libraries to implement this DEC VAX feature. Wakker: Agrees with Harris, don't give a reasonable answer to an unreasonable question. General agreement to retain the max_arg_PROC and arg_too_big concepts. Issue 41) Rabin: Clause 10: Need to explain why usage of the terminology "arg_too_big notification" is OK. Suggest changing the wording. General: agree. Issue 42) Scowen: Clause 10.8 and later: Need to define the use of the symbol "backwards epsilon" meaning "such that". General agreement. Issue 43) Kakehi: Also for "backwards E" meaning "there exists". General agreement. Kakehi: Also prefer ":" for "such than" rather than "backwards epsilon". Issue 44) Wakker: Clause 10 Note 1: Change "implementation dependent and must be documented" to "implementation defined". General agreement. Issue 45) Scowen: Clauses 11.7, 11.8, 11.11, and 11.12: remove they "(Y,X)" from the clause headings. General agreement. Issue 46) Scowen: Clause 13: Suggests adding functions for conversion from I (integers) to F (floating point). Harris: Disagree, not needed. Meek: Purpose is to record notifications for the overflow cases Barkmeyer: Agree Meek: Some languages support unbounded integers - LISP notably. Also, note, need not be represented as a function Consensus: Include functions for integer to floating conversion (ed. Editors point out that these already exist in LIA-1. Editors suggest adding a note pointing out this fact and take no other action.) Issue 47) Editor and Scowen: Remove Clause 14. General discussion, mostly in agreement with proposal. Lozier: LIA-2 specifically applies to floating point issues Wakker: Language standards have jurisdiction here, nothing LIA-2 says will affect their behavior. Propose removal - these are currently not useful. Consensus: Agree with editor's proposal. Issue 48) Karlsson and Rabin: Clauses 13.9, 13.10, 13.11, 13.12 The terminology of the "G", meaning, "a separate floating point type" in the subscripts is not described. Add a description to section 5 or 13. Short discussion. General agreement. Issue 49) Lozier: This is an inconsistent use of the subscript notation. In all other sections, subscripts denote input number and type only. Here, they denote input and output type. Since all inputs are "F" type, no harm in removing them from the subscript, allowing removal of the "G" notation entirely. Harris: Bindings will specify alternate names for all of these functions anyway. Discussion: Alternative is to discuss this difference in section 5. Still need a representation for an alternate floating type in the Signature and Definition portions. Consensus: Let editors address this issue as they see fit. Lozier: Prefers simplification in this section. Issue 50) Wakker: Section 13.9, 13.10: Subtitles "lower float", "upper float" are not standard terminology. In fact they are just different roundings and the function names "FLOOR" and "CEILING" are only loosely using the notions of the floor and ceiling concepts in mathematics. Suggest making the subtitles reflect the actual behavior. General agreement. Issue 51) Editors: Clauses 16.5 to 16.8: Suggests removal. These are just simple compositions of existing functions with no added precision. General agreement Issue 52) Editors: Clause 19.2: Suggests removal. Precision specification is difficult and not easily justifiable. Motivation is also questionable. General agreement Issue 53) Scowen: Annex E: Suggests moving to Clause 4.2 and deleting. Wakker: Suggests 3 steps: 1) Remove items that are also defined in 4.2. 2) Remove items that are not referenced in LIA-2 3) Move the remainder to section 4.2. The precedence of a Glossary in LIA-1 is not compelling. Kakehi: Glossary does not provide significant added value Rabin: Suggests an index instead. Wakker: Agree with Rabin. Consensus: Let the editors address this issue as they see fit. Meeting prefers Wakker's suggestion and Rabin's suggestion. Issue 54) Kakehi: Clause 3: Add normative reference to LID, soon to be published (nudge to Barkmeyer to complete editing!). Use for "sequence type", etc. General agreement. Wakker: Reference is ISO/IEC 11404:1995 Issue 55) Kakehi: Clauses 11.7, 11.8. These do not currently use the "approximates" notation in the definition. Suggests "ordinary" style definition, and making the usage information (now in the Definition portion) into a Note. General agreement. Issue 56) Kakehi: Clauses 11.11, 11.12, Definition portion. This is the only place where the right-hand side of the definition refers to other LIA-2 functions, rather than giving mathematical notation. Suggests expanding to a full definition, perhaps adding a note about possible implementation using the other function. Consensus: Leave this up to the editor's discretion. Issue 57) Lozier: Clause 19.1: Note use of "ulp" in clause 19.1. Is this an oversight? Wednesday, 27-Sep-1995 Meeting info: Harris to investigate possibility of meeting in the Boston area in Fall 1996. Technical and editorial issues from Karlsson's email messages: Issue 58) Karlsson: Suggests informative annex with language binding. Harris: Volunteers to work with editors to develop a C language binding. No short-term schedule commitment, but will attempt to have in time for DIS ballot. Lozier: Volunteers to help review this section informally. Wakker: Agree, thanks. Issue 59) Karlsson: Clauses 19.5, 19.6: Definition portion. Disagrees with "v is-an-element-of Z", since mod_I not defined for 0. Discussion: Change Z to I. General agreement. Also: remove "and n is-an-element-of I" from 19.7 and 19.8. Also: add "and n is-an-element-of I" to 19.5 (see Axiom, use of "n") Also: eliminate overloading of "=" and "/=" in definitions of 19.7, and 19.8. For instance, in 19.8: EVEN_I(x) = true if mod_I(x,2) = 0 = false if mod_I(x,2) /= 0 Issue 60) Karlsson: Clause 8.5. Note that the EXP functions have tighter accuracy bounds than the corresponding "POW" functions that they are "equivalent" forms for. Does this imply that the POW forms also have the extra accuracy requirements? Much discussion. Consensus: No, but the current formulation is confusing. Suggestion: Remove references to the POWER functions entirely, they aren't needed, the proper definition is given below the "table". Add a Note to the effect that they are equivalent to the POWER functions, with a comment on the tighter accuracy requirements. Comment: This issue doesn't seem to arise in the other "special" cases. Lozier: Suggest that these two special cases be split into two separate sections. Consensus: Leave to editor's discretion. Issue 61) Karlsson: Rounding from floating to integer supports biased rounding. Insists on unbiased rounding (halfway case always rounds to nearest). Lozier: Prefers current formulation Meek: This is a topic that has already been decided in favor of the current formulation. Harris: This is an "implemenation defined" behavior. Unbiased rounding implementations are allowed and encouraged. Meek: Suggests adding "rounding bias" to the list of required documentation. Consensus: agree. Meek: Also suggests adding a run-time inquiry function to query implementation treatment of rounding bias. c.f. max_error_PROC Wakker: Suggests that access to parameter for rounding bias be in a separate section. Harris: Note that this only applies in sections 7 and 13 functions. Issue 62) Karlsson: Clause 5.2 item e): What does this monotonicity requirement mean for 2nd argument of the 2 argument trig functions. It is essentially a meaningless concept to hold the value constant while varying the units - you are actually varying the angle. And how would you hold the angle constant while varying the units? That would involve varying both parameters at once. Harris: The concept is meaningless, but the operation and requirements are clearly defined, and not difficult to satisfy. Meek, Wakker: Suggest that we eliminate the monotonicity requirement for the units argument for the 2 argument trig functions. Specify the exception in 5.2e and note in clauses 10 and 11. Harris: Agreed. What about the base arguments in POWER and LOG cases? General: Leave monotonicity requirements alone for those. Wakker: Suggests "Implementation defined" for monotonicity requirement on the units argument for the trig and inverse trig functions. General agreement. Issue 63) Karlsson: Insists on removal of "truncation" type rounding operations. Harris: Keep because of IEC 559 "round toward 0" requirement. Also, when rounding to a specific level of precision, common practice to "add .5 and truncate". Meek: Shouldn't be revisiting resolved issues. General agreement. Wakker: How to address other issues in Karlsson's email messages? Suggestions for editors: 1) For issues that have actions required from this meeting, take the appropriate action. 2) For issues that were resolved in favor of the current document text, consider for discussion in the appropriate section of Annex A. 3) Reply to his messages concerning each item acted upon 4) Cite meeting discussion or rationale for each issue General agreement. Wakker: Schedule issues for next steps: If we have a meeting, as offered by Keld Simonsen in Copenhagen on 15-19 April 1996, then we need a CD registration draft in 4 weeks. In this case, the CD registration ballot can start in November and run until March for ballot resolution in mid-April. Can get comments earlier from US, UK, NL, and Sweden of course. Do the editors think this schedule is possible? Harris: Cannot commit at this time. Will consult and report in 1st week of October. Wakker: Proposal: Send LIA-2 document, as amended at this meeting, to CD registration and CD ballot? All but Sweden: Yes Proposal passes Proposal: Designate this draft to SC22 Secretariat as "final CD". Explains implications - mostly procedural All but Sweden: Yes Proposal passes