Subject: WG11/N419: report on LIA-2 discussion (part 2 of 2)

From: Willem Wakker <[email-masked]>
Date: Thu, 05 Oct 95 12:01:18 N

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