Message-Id: <9510041810.AA25000@us2rmc.zko.dec.com>
Date: Wed, 4 Oct 95 14:10:21 EDT
From: "Kevin Harris, DTN 381-2039, or 603 881 2039" <harris@cairn.ENET.dec.com>
To: willemw@ace.nl
Cc: harris@cairn.ENET.dec.com, payne@hpcgrp.ENET.dec.com,
        schaffert@crl.ENET.dec.com
Apparently-To: willemw@ace.nl
Subject: Willem, I've made your suggested edits (with minor changes).  Here's a version for publication to WG11. -Kevin

ISO/IEC JTC1 SC22 WG11

Meeting at NIST, Gaithersburg, MD, USA, 25-Sep-1995 to 27-May-1995

Notes on the discussions of SC22/WG11 document N416, editor's draft of LIA-2,
dated 6-Sep-1995.
Notes taken by: Kevin Harris, Digital Equipment Corp

	additional comments added by the note-taker after the meeting are
	introduced by the notation: "(ed ....)"

Additional documents forming the basis for the discussions:

1) "Cover Letter for SC22/WG11 N 416", by Mary Payne, dated 4-Sep-1995
2) Marked up copy of SC22/WG11 N 416, from Roger Scowen
3) Editor's written proposals carried to the meeting:
	16-Sep-1995: Draft Specs for EXPM1 and LN1P
	20-Sep-1995: "Two Proposals for Changes to LIA-2"
		1) Removal of clause 14 and its subclause
		2) Removal of clause 19.2
	20-Sep-1995: "Another Proposal for Changes to LIA-2"
		Removal of the "max_arg_PROC and "argument_too_big" concepts
	20-Sep-1995: "Yet Another Proposal for changes to LIA-2"
		Limitation of the accuracy requirements for 2 argument
		trigonometric functions.
	20-Sep-1995: 2 messages on the specification style of the SQRT
		functions
4) Email message from Roger Scowen, 8-Sep-1995, "LIA-2 Cover Letter Response"
5) Email message from John Diamond, 15-Sep-1995, "LIA-2", opinions on topics
	raised in the cover letter.
6) Email messages from Kent Karlsson:
	SC22WG11.570, 21-Sep-1995: "Some (many) discussion points for the WG11
			late September 	meeting" which references to 4 earlier
			messages:
	4-Aug-1995: "Suggested section on LIA-2 integer operations, with "new"
semantics for those integer operations."
	8-Aug-1995: "Suggested section on LIA-2 basic floating point operation
s, with "new" semantics for those floating point operations."
	21-Aug-1995: "Part 1 of suggested LIA-2 section on elementary
transcendental f.p. operations, with "new" semantics for those floating point
operations."
	8-Sep-1995: "Part 2 of suggested LIA-2 section on elementary
transcendental f.p. operations, with "new" semantics for those floating point
operations."
	25-Sep-1995: "Re: LIA-2 at the next meeting"
	25-Sep-1995: "Re: Kent's comments on minimum and maximum procedures"
	25-Sep-1995: "Re: Corrected trig comments"

Meeting minutes:

Attendence:
	Willem Wakker, Netherlands
	Brian Meek, UK
	Kevin Harris, USA representing LIA-2 editors Mary Payne, Craig Schaffert
	Ed Barkmeyer, NIST, USA, host
	Hiko Kakehi, Japan
	Dan Lozier, NIST, USA
	Paul Rabin, OSF, USA

Reports regarding LIA:

    From the SC22 Plenary at Annapolis, 18-22 Sep 1995:

	Resolution AH: Authorization for concurrent CD registration and ballot
			for WG11 documents

ISO/IEC JTC1/SC22 authorizes the SC22 secretariat to conduct a concurrent CD
registration and CD ballot for project 22.33 - Language Independent Arithmetic,
Part 2: Mathematical Procedures.

	Resolution AI: Change of titles for WG11 projects:

ISO/IEC JTC1/SC22 approves the change of titles for parts 2 and 3 of the
Language Independent Arithmetic Standard (ISO/IEC 10967):
	- part 2 (project 22.33), new title: Elementary Numerical Functions
	- part 3 (project 22.34), new title: Complex Floating Point Arithmetic
		and Complex Elementary Numerical Functions

	Resolution ZB: Appreciation: general

ISO/IEC JTC1/SC22 expresses its appreciation to all those who have assisted in
the work of this meeting, and in particular
	. . .
	to Mr. Kevin Harris for his informative presentation on Language
		Independent Arithmetic;
	. . .

    Liaison Report from UK:
		Happy to see LIA go to CD registration without delay - no
		further meetings needed.
    Liaison Report from USA:
		No WG11 liaison specific activity.  X3T2 happy with current
		progress of Language Independent work.

Discussions regarding LIA-2:

Monday, 25-Jan-1995

Harris: Presents summary of the changes to the LIA-2 draft since the last
	meeting and the current issues:

    Editor's issues:
	1) Clause 2.1; Should we retain the concept of "Conformity to the
	whole"?
	2) Clauses 4.1 and A.4.1; Duplication of definitions issues
	3) Clause 7; Modify the Description for SQRT_F, use approximation
		style
	4) Clauses 8 and 9; Inclusion of EXPM1 and LN1P functions
	5) Clauses 10 and 11; Modify accuracy requirements for 2 argument
		trigonometric functions
	6) Clauses 10 and 11; Removal of the "argument too big" concept
	7) Clause 14; Removal of conversions between Integer Signed and Unsigned
		forms
	8) Clauses 16.5-16.8; Removal of Max/Min with conversions
	9) Clause 19.2; Remove POLY

    Scowen's general comments:
	1) Congratulations on a well constructed draft
	2) Rationale section still incomplete in many areas
	3) Where text is taken verbatim from LIA-1, please indicate in (draft)
		forms as an Editor's note.  This will allow reviewers to
		concentrate on new LIA-2 text, and limit debate on previously
		resolved issues.
	4) Clauses 7.1 and later: Move all requirements concerning extensions
		to an annex.
		Meek: Clarification: There is a problem with conformance rules
		regarding IEC 559 conforming implementations.  Need to make it
		clear that if IEC 559 conforming implementations support
		extension rules for any supplied functions, they must support
		the extension rules for all supplied functions.  Extension
		support is an all-or-nothing support issue.

    Harris: Volunteers to make a detailed list of Scowen comments for the
		next day's discussion.

    Karlsson's general comments: Email message (SC22WG11.570) "Some (many)
	discussion points for the WG11 late september" from 21-Sep-1995

	Barkmeyer: Distributes printed copies (SC22 plenary attendees were
		travelling and couldn't receive email) and WG11 attendees
		review and discuss:

	Harris: Summarizes editor's issues with the Document structure (section
	2 of SC22WG11.570) and Semantic style and notational style (section 3
	of SC22WG11.570) proposals:
		1) The number of changes required is very large.
		2) Even assuming WG11 agreed with all these proposals, the
			document changes implied would require extensive
			editing, requiring an estimated 1-2 years to reach
			the level of confidence that we now have in the current
			document.  In particular, the fact that the specified
			semantics of each procedure are potentially changed
			as well as the format of their description, implies
			that a lengthy review and comparison will need to be
			made for each function.
		3) Publication timeliness is important, for example, the
			WG14 meetings (next C standard) are considering
			arithmetic conformance and LIA bindings issues now.
		4) Agreement is strongly in doubt on many of these proposals.
			Many have been raised previously and rejected by
			consensus of attendees at prevous meetings.  Many
			make unwarranted assumptions and claims.
		5) The SC22WG11.570 document points out several technical
			problems and weaknesses in the current draft.  These
			are acknowledged and can be addressed without radically
			changing either the format of the specifications or
			the organizations of the document.
		6) Almost all the proposals in (SC22WG11.570) are specified
			as "make or break", i.e. Karlsson will vote no on
			forwarding the document unless these changes are made
			in his suggested fashion.  It is unlikely that the
			editors and WG11 generally will agree to his view on
			all these points.  Thus, based on the current views
			expressed in SC22WG11.570 and its supporting documents,
			it is not likely that Karlsson would support the
			progression of any document that the editors and the
			balance of the WG11 members could agree on.
		7) The intended audiences for the LIA family of standards are
			hardware and software vendors, and other standards
			writers.  Strict adherence to existing practice in
			notation used by the refereed mathematical publishing
			world and their readers is not required.  Instead, the
			virtues of clarity, internal consistency, and
			practicality of implementation are emphasized.

		Thus, the editors suggest that major specification style changes
		and document organization changes proposed in sections 2 and
		3 of SC22WG11.570 and its supporting documents not be
		considered further by WG11.

	Wakker: Supports the position of the editors.
		There are a variety of time pressures that must be considered
		Wants to accept the major concerns of Kent that can be
			addressed without significantly delaying CD registration
		Has not received any negative comments from SC22 national
			representatives or WG convenors concerning LIA-2
		Would prefer to basically continue in the current mode with
			current document structure and formatting

	Kakehi: Supports Wakker.
		Most important issues are: 1) Technical correctness
					   2) Timeliness - especially with
					   imminent LID and LIPC publication
	Meek, for UK:
		Happy with overall document structure.
		Repeats request that text replicated from LIA-1 be marked,
			so as to avoid reviewers needing to raise problems with
			such text.
	Meek, personal:
		Don't like to dismiss restructuring just because of time
		pressure.
		Advocates careful consideration of structure for general
		benefits.
		The LIA-1 approach has benefits.
		But don't agree with many of Karlsson's assumptions and
		    conclusions:
			Side by side reading of LIA-1 and LIA-2
			    The two documents will not be read by the same
			    people and not at the same time.
			More concerned with notation than document structure
			    Good benefits from current structure
			    Seeing all aspects of a given function in one place.
		The case for a major change isn't strong enough
		Had it been done in the LIA-1 style originally, there would
			be requests to convert it to the current style
		There are both technical and practical reasons for using the
			current style.

	Lozier: Don't have a problem with the current structure, not a weakness
		Perhaps there are important technical comments to consider
		A standards document is not a mathematical document
		Editors should accommodate technical comments as necessary.

	General consensus: adopt the suggestion of the editors.

Wakker: Presents "best case" schedule for LIA-2:

	Canonical voting requirements:
	Step 0) WG11 agrees LIA-2 draft is a "Committee Draft" (CD) ready
		for outside review.
	Step 1) Register working document as a CD (4 month ballot).
	Step 2) If CD registration ballot passes, hold a CD content ballot
		(4 months).
	Step 3) If the CD content ballot passes, and it was designated as a
		"final" CD content ballot, request permission to hold a DIS
		country ballot. If successful, 4 month ballot DIS ballot.
	Step 4) When step 3 is complete, with adequate votes, DIS is slightly
		modified to accommodate comments, and published as an IS.

	Under recent rule changes, it is now allowed to request that steps 1
	and 2 be combined.

	WG11 received permission to combine steps 1 and 2 for LIA-2 (see
		resolution AH above)
	New DIS rules starting 1-Apr-1996: Only very minor editorial changes (
		spaces, obvious misspellings) are allowed after a
		successful DIS ballot.
	ITTF (editorial style) comments are provided as part of a "final" CD
		content ballot.  These comments must be accepted.

	So, at best, WG11 could achieve the following schedule for LIA-2:
		1) Revised draft by end of October 1995, short review by WG11
			by email (yes/no), send to SC22 Secretariat for 4 month
			CD Registration/Content ballot, complete by Feb '96.
		2) WG11 meeting in April to consider ballot comments
		3) DIS draft text by May for WG11 approval
		4) Send to SC22 secretariat in June for DIS country ballot,
			complete by Oct 1996.
		5) Resolve ballot comments, publish IS in Dec 1996.

Wakker: Presents balloting rules

	CD content balloting rules are unclear.  Must achieve "substantial
		support".
	DIS balloting rules are concrete:
		1) 2/3 or more "P" members must vote positively.  Abstaining
			"P" members are not included in this fraction.
		2) No more than 1/4 of all members (including "O" members)
			may vote against.  Abstaining "P" members are counted
			as members in this fraction.

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