Showing content from http://754r.ucbtest.org/minutes/2017-05-19-minutes.txt below:
754R Minutes - 19 May 2017 Recorded by David Hough Also at: http://754r.ucbtest.org/minutes/2017-05-19-minutes.txt The 754R revision group met by teleconference on 19 May 2017: convened at 8:00am and adjourned at 10:00am Pacific Daylight Time. Teleconference participants: David Chen Cadence Marius Cornea Intel Mike Cowlishaw Univ Warwick Jim Demmel UC Berkeley Ken Dockser Qualcomm David Gay AMPL Optimization Ivan Goddard Mill Computing Roger Golliver unaffiliated Michel Hack IBM David Hough unaffiliated Christoph Lauter Sorbonne University Terje Mathisen Mill Computing Rich Painter unaffiliated Jason Riedy Georgia Tech Eric Schwarz IBM Jim Thomas unaffiliated Leonard Tsai unaffiliated Lee Winter unaffiliated The IEEE-SA slides were referred to; the URL is: https://development.standards.ieee.org/myproject/Public/mytools/mob/slideset.pdf Officers: A request for volunteers to serve as vice-chair and secretary was met with deafening silence. Meetings: Teleconference-only meetings are scheduled for Friday 9 June, 14 July, 8:00-10:00 am Pacific Time. ACTION ITEM SCHWARZ: Contact ARITH-24 chair to see if a meeting room and phone support can be arranged for Sunday July 23 in London, in lieu of 14 July teleconference. Mailing list: Anybody may subscribe to the mailing list; send any email to: STDS-754-subscribe-request@LISTSERV.IEEE.ORG Website: The website 754r.ucbtest.org, left over from the previous effort, is being used for the time being. ================== Topics: ===== Draft review. * Approved the editor's draft 220 incorporating the decisions of the previous meeting. http://754r.ucbtest.org/drafts/P754-220.pdf ===== Draft review. "is NaN" vs "is a NaN" However "is a NaN" appears more frequently in the document. To be consistent: AI DONE EDITOR: replace usages like "is NaN" with "is a NaN" wherever appropriate. ===== "datum" vs "number" In description of min/max ops, "datum" is sometimes used where "number" would suffice. Glossary defines "floating-point datum". ACTION ITEM Thomas, Hack, Editor: Replace "datum" with number where possible, and with "floating-point datum" otherwise, and report any further complications. ===== old min/max ACTION ITEM Hack: Look at pp 57 and 60 and elsewhere for stale references to the old min/max functions. ACTION ITEM ALL: Be on the lookout for other stale references from 2008 invalidated by our changes in 2018. ===== Augmented ops + - * Thomas: In trying to draft a C binding for augmentedAddition, a few issues occurred to me. One is the use of "x+y". Note that the standard uses expressions like x+y as mathematical operations, typically on the extended reals (or as a language expression). Other issues are about editorial consistency with the standard. See comments below. (sourceFormat, sourceFormat) augmentedAddition(source, source) The operation augmentedAddition(x, y) computes both the exact sum x+y rounded to sourceFormat using the roundTiesToAway rounding Replace "exact" with "infinitely precise". (The use of x+y is appropriate here.) attribute and the error in rounding the sum when the rounded x+y is finite. This operation is specified only under default exception handling (Clause 7). If roundTiesToAway(x+y) denotes the infinitely precise result of x+y rounded to sourceFormat using the roundTiesToAway rounding attribute, then augmentedAddition produces roundTiesToAway(x+y) and x+y-roundTiesToAway(x+y) when roundTiesToAway(x+y) is a finite number. I think this should be "finite non-zero number", because the two expressions don't always compute the same sign of zero. If x+y is zero, both produced results are the result of x+y (and have the same sign). This may be correct, but for parallelism, roundTiesToAqay(x+y) would be better than x+y. This operation's exceptional behavior is the same as addition (Clause 5.4.1) with the following additional specifications. "addition" should be bold. Also, "addition" should be qualified with "using the roundTiesToAway rounding attribute". The operation propagates a NaN as both results if any input is NaN (Clause 6.2.3). If x+y is infinite, both produced results are the result of x+y, and the "x+y" should be "roundTiesToAway(x+y)" here. x+y (being an operation on extended reals) is infinite only in cases where x or y is infinite, but this is intended to apply to overflow too. operation signals like x+y. "x+y" should be "addition(x, y) using the roundTiesToAway rounding attribute". If x+y is invalid (Clause 7.2), the operation is invalid and produces the same quiet NaN for both outputs. The standard doesn't say "is invalid" anywhere else. We might say "If the operation signals invalid, it produces the same quiet NaN for both outputs." We've already said that the exceptional behavior is like addition .... The operation signals inexact only when roundTiesToAway(x+y) overflows. With the suggested changes above, the first bullet in 9.5 becomes * (sourceFormat, sourceFormat) augmentedAddition(source, source) The operation augmentedAddition(x, y) computes both the infinitely precise sum x+y rounded to sourceFormat using the roundTiesToAway rounding attribute and the error in rounding the sum when the rounded x+y is finite. If roundTiesToAway(x+y) denotes the infinitely precise result of x+y rounded to sourceFormat using the roundTiesToAway rounding attribute, then augmentedAddition produces roundTiesToAway(x+y) and x+y -roundTiesToAway(x+y) when roundTiesToAway(x+y) is a non-zero finite number. If roundTiesToAway(x+y) is zero, both produced results are the result of roundTiesToAway(x+y) and have the same sign. This operation's exceptional behavior is the same as addition (Clause 5.4.1) using the roundTiesToAway rounding attribute, with the following additional specifications. The operation propagates a NaN as both results if any input is a NaN (Clause 6.2.3). If roundTiesToAway(x+y) is infinite, both produced results are the result of roundTiesToAway(x+y) and the operation signals like addition(x,y) using the roundTiesToAway rounding attribute. If the operation signals invalid, it produces the same quiet NaN for both outputs. The operation signals inexact only when roundTiesToAway(x+y) overflows. ACTION ITEM Thomas and Editor: Examine these changes, make them where appropriate, call attention to any problems encountered. ===== encode/decode vs signaling/quiet nan differentiation (in context of C): Hack and Thomas: The following could be added as a note at the end of 3.1.1: Export and import of interchange format data normally occur as sequences of octets, e.g., in a file or a network packet. There is therefore a need to define the octet-encoding that maps the conceptual Level 4 bit string encodings of floating-point data into octet sequences. Applications exchanging data need to describe the types and layout thereof; this standard defines the representation of individual data as conceptual Level 4 entities. Environments whose primary focus is universal portability (e.g., Java) may fully define the representation at the level of an octet sequence, even when this does not match the natural in-memory layout of the platform. The standard merely requires the parameters of the octet-encoding be communicated, which may avoid conversion costs when bulk data are exchanged among similar systems. Those parameters are: * byte order (Endianness): Big-Endian, Little-Endian, or mixed (in the last case it might be useful to export a template); * for binary formats, how signaling NaNs are distinguished from quiet NaNs; * for decimal formats, whether BID or DPD encoding is used. The standard does not define how this information is to be conveyed. This is not a limitation because applications must already agree on what it is that is being exchanged. Problems: octets, template, Java... many things mentioned that are not necessary. Interchange formats are defined before encodings are defined. ACTION ITEM Hough: Revise text to better fit 3.6. ===== binary nan encoding Previous discussion of interchange formats turned up many issues of binary NaN encoding: what is implicit vs explicit: what is required (q/s based on d1), what is recommended (d1=0 implies q; d1=1 implies s), what is implementation defined (how conversion of quiet to signaling works when d1=1 implies s). ACTION ITEM Hack: Propose a revision of text that puts the essential binary NaN formatting information in 3.1 and clarifies the above issues. ===== minNum/maxNum associativity Bob Alverson: A question came up about the minNum and maxNum functions in the draft spec. It looks like: minNum( 1, QNaN ) = 1, without exception minNum( 1, SNaN ) = QNaN, with invalid exception This makes me wonder if anyone is worried about associativity for this operation. For example, minNum( 1, minNum( 1, SNaN ) ) = 1 but minNum( minNum( 1, 1 ), SNaN ) = QNaN. Both groupings would raise invalid so one should know something is up. However, I can imagine different compilations or runs with parallel processing returning different answers, depending on whether the SNaN was encountered last or not in a sequence of minNum operations. For all the previous discussion, see previous minutes. AI DONE Hack and Editor: Complete the specification for the eight min/max functions and associated 6.2 change, preserving the Preferred Exponent language, and deleting reference to the 2008 min and max functions. both operands are NaNs, the signaling NaN is discarded and not converted to a quiet NaN as stated in 6.2 for other operations. Note that "discarded" is not used elsewhere in the standard. We need better wording to convey our intent. ACTION ITEM Winter: Propose a revision to the two instances of "discarded". ===== what does provide mean? Lefevre: In 3.1.2 Conformance: A conforming implementation of any supported format shall provide means to initialize that format and shall provide conversions between that format and all other supported formats. A conforming implementation of a supported arithmetic format shall provide all the operations of this standard defined in Clause 5, for that format. This is not clear. What if a language "provides" some operation, but this operation is restricted to some context? For instance, in C99 and C11, one cannot portably use fma() in initializers of objects with static or thread storage duration, as this is a function call, and the C language provides no exceptions for such standard functions. Is this conforming or not? RESOLUTION: No change. The section 3.1.2 Conformance is necessarily somewhat general and vague, to encompass many kinds of language systems. Whether and how languages support data initialization, including whether initializing expressions are allowed and what happens if they are exceptional, is left to languages to define. Hough: Perhaps we want to add a line stating that we WANT each language to define something specific. ===== Functions specifying NaN signs Bruno Le Floch: In "6.3 The sign bit" it is stated that "operations on bit strings â copy, negate, abs, copySign â specify the sign bit of a NaN result". The list of four functions could be construed as being complete, but it is (at least) missing isSignMinus. Indeed, "5.7.2 General operations" states that "isSignMinus applies to zeros and NaNs as well". I see two ways to correct this: (1) Add isSignMinus to the list in 6.3. (2) Add "for instance" before the list in 6.3. ACTION ITEM Editor: Add "isSignMinus" to "totalOrder" in the list of functions that look at the sign bit and return logical predicates. ===== Chapter 9 Over- and Under-generalizations The beginning of chapter 9 contains a lot of generalizations about the functions listed in the chapter and what language standards should do about them. Some of these generalizations specify too much, and some too little. AI DONE Thomas: Propose a list of issues about generalizations. Response: Clause 9 includes subclauses for these operations: 9.2 correctly rounded 9.3 dynamic modes for attributes 9.4 reduction 9.5 augmenting arithmetic precision 9, 9.1, and 9.1.1 are positioned in the document to apply to all the remaining subclauses. 9 page 47, iine 3. Says "This clause specifies additional operations recommended for all supported arithmetic formats." Not true for 9.5 (and not applicable for 9.3). Recommendation: delete "for all supported arithmetic formats" 9.1 page 47, lines 8-10. Says "For one or more formats, language standards and implementations might define one or more floating-point operations, not otherwise defined in this document, that conform to this standard by meeting all the requirements of this subclause." What does "this subclause" refer to? Recommendation: Replace "by meeting all the requirements of this subclause" by "by meeting the requirements in this clause". page 47, lines 10-11. Says "... language standards should define, to be implemented according to this subclause, as many of the operations of 9.2 and 9.5 as are appropriate to the language." This applies to 9.3 and 9.4 too. Recommendation: Change "9.2 and 9.5" to "9.2 through 9.5" page 47, lines 11-13. Says "The specifications for inexact exceptions in previous clauses do not apply to the operations specified in this clause." This could be taken as saying there is no specification of inexact exceptions for these operations. Recommendation: insert at the end of the sentence the clause "; specification of inexact exceptions is included with the specification of operations in this clause". page 47, lines 14-16. Says In this clause the domain of an operation is that subset of the affinely extended reals for which the corresponding mathematical function is well defined. A conforming operation shall return results correctly rounded for the applicable rounding direction for all operands in its domain. These two paragraphs apply to 9.2, but not to 9.3-9.5. (The first paragraph might apply to 9.4 and 9.5, but we don't state the domain for addition and such.) Recommendation: Move to after first the paragraph in 9.2 9.1.1 page 47, lines 18-30. Says Except as specified here, operations signal all appropriate exceptions according to 7. An operation that returns a floating-point result shall return a quiet NaN as a result if there is a signaling NaN among the operation's operands. An operation that returns a floating-point result shall return a quiet NaN as a result if there is a quiet NaN among the operation's operands, except in the cases stated otherwise in 9.2. -- invalid operation: For all operations, signaling NaN operands shall signal the invalid operation exception. Attempts to evaluate an operation outside its domain shall return a quiet NaN and signal the invalid operation exception. -- divideByZero: An operation that has a simple pole for some finite floating-point operand shall signal the divideByZero exception and return an infinity by default. -- inexact: Operations should signal the inexact exception if the result is inexact. Operations should not signal the inexact exception if the result is exact. This paragraph appears to be intended to give specification about exceptions that apply to all the relevant operations in the clause. It applies to 9.2 (with some redundancy), but 9.4 and 9.5 have their own specifications for exceptions, which in some cases contradicts 9.1.1 (e.g., the inexact specification in 9.5 is SHALL, not SHOULD). Recommendation: Move the content of 9.1.1 to 9.2 and adjust the introductory text in 9.2 accordingly. More below. Regarding the second and third sentences in current 9.1.1, all these operations (that have floating-point operands) return floating-point results. Recommendation: Delete "that returns a floating-point result", twice. After following the recommendation above, the second paragraph of 9.2: All operations shall signal the invalid operation exception on signaling NaN operands, and should signal the inexact exception on inexact results, as described in 9.1.1; other exceptions are shown in the table. might change to: Except as specified here, operations signal all appropriate exceptions according to 7. An operation shall return a quiet NaN as a result if there is a signaling NaN among the operation's operands. An operation shall return a quiet NaN as a result if there is a quiet NaN among the operation's operands, except in the cases stated otherwise in this subclause. -- invalid operation: For all operations, signaling NaN operands shall signal the invalid operation exception. Attempts to evaluate an operation outside its domain shall return a quiet NaN and signal the invalid operation exception. -- divideByZero: An operation that has a simple pole for some finite floating-point operand shall signal the divideByZero exception and return an infinity by default. -- inexact: Operations should signal the inexact exception if the result is inexact. Operations should not signal the inexact exception if the result is exact. Other exceptions are shown in the table. 9.2 page 52, line 6. Says "and signals the inexact exception". All other such cases in 9.2 say "can signal the inexact exception", since the inexact exceptions are not required for 9.2 operations. Recommendation: Change "signals" to "can signal" 9.4 page 53, line 38. Current text for 9.4 doesn't mention inexact. Recommendation: After line 38, insert the paragraph: These operations signal the inexact exception with overflow and underflow. Otherwise, the inexact exception is not specified for these operations. ACTION ITEM Riedy: Examine Jim's proposed changes and report. Prepare a revision of Chapter 9 with red/green encoding so we can more easily assess the scope and completeness. ===== formatOf operations between integer and floating-point types Lefevre: I think that IEEE 754 should standardize formatOf operations between integer and floating-point types. Basically, the specification would be reduced to the case where the integer is 0 (which is not signed) since for the other integers there would be no ambiguity (possibly except concerning DFP's cohorts, which could be specified as well). The reason is that some languages and software (like the GNU MPFR library) may allow operations between integer and floating-point types *without an implicit conversion* (thus unlike in C). FYI, from https://sympa.inria.fr/sympa/arc/mpfr/2017-04/msg00020.html ------------------------------------------------------------------------ From: Vincent Lefevre To: mpfr@inria.fr Subject: Re: [MPFR] Division by zero Date: Tue, 18 Apr 2017 05:18:37 +0200 On 2017-04-18 09:47:41 +1000, sisyphus1@... wrote: > For non-zero (and non-nan) operands, I'm finding that division by > unsigned zero is returning @Inf@. > Shouldn't @NaN@ instead be returned ? An infinity was chosen on purpose in 2000, and at that time, the rules were not clear. The status of the unsigned 0 (depending on the context) is still not very clear actually. Now, I think that what matters here is that an integer 0 is necessarily exact, so that choosing a rule based on the limit x -> 0 (with x being a real number) doesn't make much sense. So, the result should be NaN. And the choice of returning -Inf for mpfr_log_ui (new function in the trunk) on 0 is questionable, except if at Level 1, log is regarded as a function on the extended real numbers, i.e. log(0) would mathematically be defined as -inf. Riedy response: We carefully avoid discussing integer types to avoid having to *define* integer types. I would not be comfortable adding them at this stage of *this* draft, but some mechanism to define interaction may be feasible for the next round. Stephen Canon response: If, as Vincent says, all that needs to happen is to define the arithmetic for (unsigned) zero, presumably the standard could define arithmetic on any source operands representing real values and producing a floating-point result only by reference to the represented (extended) real values, without needing to define additional (not floating-point) types or encodings. I agree that this seems out of scope currently, however. RESOLUTION: 5.4.2 line 18 already states that an unsigned zero converts to a positive zero in floating-point format. Further specification of integer formats is too big a project for 2018. ===== Disappearing NaNs Tydeman: Please add to section 6.2 Operations with NaNs, words along the lines of: In a computation, if a NaN is replaced by any finite or infinite value, and the result of the computation is the same value, use that value, otherwise, use a NaN. For example, hypot(infinity,NaN) is an infinity no matter what value is used for the NaN. RESOLUTION: This sentence doesn't add anything normative and belongs in a separate background document. Redundantly specifying this behavior risks implying subtle differences that don't exist. We are not going to change 2008 behavior that is working as intended. ACTION ITEM anybody interested: provide a brief background document discussing this issue. Include reference to https://people.eecs.berkeley.edu/~wkahan/ieee754status/IEEE754.PDF page 7. ===== Multiple NaN flavors Somewhere we should expose the real issue, which is not in our power to deal with: the need for standard distinguished NaN types for "invalid" and for "missing". Vincent Lefevre comment: You forget a 3rd type of NaN: one obtained from a rounding error. Indeed, just because of rounding errors, a value may be slightly outside the domain of a function. Unfortunately, it is not possible to distinguish it from "invalid". This 3rd type of NaN is the main reason behind the choice to return the constant for constant functions (in addition to allowing better optimizations), i.e. this really makes sense and is 100% safe. Terje Mathisen response: How is this possible? Lefevre: If you compute sqrt(x*x - x*x) with a FMA, this can give you a NaN.) AI DONE Ivan Godard and Lee Winter: Propose an encoding for missing value NaN, describe how it would affect the semantics of standard operations, and describe how it could be incorporated in 2018 in an upward-compatible fashion. The majority of the working group are doubtful that this can be usefully addressed in an upward-compatible way, and so should be deferred to 2028. Godard proposal: http://754r.ucbtest.org/docs/godard-proposal-none.pdf is the proposal for missing-value I promised at the last teleconference. Notes: 1. I christened such objects "None" in line with Mill terminology; "missing" or another term is welcome. 2. The bitwise representation is left TBD. It's been suggested to steal a NaN payload bit, which would require changes in the bit definition of NaNs too. 3. None trumps NaN everywhere 4. Nones compare unordered 5. Reduction, max and min silently consume None, otherwise the None propagates 6. Conversions to integer signal invalid if not representable in integer (Mill can represent them) Open questions: 1. Rather than propagate, should None act like the identity of an operation if that is meaningful? (i.e. X+None == X+0.0?) ACTION ITEM ANYBODY INTERESTED: Write a background note discussing the different kinds of NaN, why we only address Missing in the context of max/min for 2018, and what might be done for 2028. ===== Can sum of squares short-circuit? ACTION ITEM anybody: Discuss whether sum of squares can short-circuit evaluation. Can't short-circuit on encountering a NaN because there might be an infinity later? Can't short-circuit on encoutering an infinity because there might be a signalin NaN later? What should be specified? For the reduction operations, must all arguments be scanned anyway in order to check for SNaNs? If so, doesn't that defeat the short-circuit idea? (The missing/invalid idea still applies of course.) RESOLUTION: no change for 2018 - worth investigating for 2028. ACTION ITEM ANYBODY INTERESTED: Write a background note explaining the issues of reproducibility vs performance in the context of vector operations. ===== background discussions Hough: We should start thinking what we might want to put together as a portfolio of background discussions to accompany drafts of the st during external review. These would be non-normative an much less than a comprehensive rationale or exegesis. Anybody who found something particularly hard to understand and would like to document his hard-won understanding might consider contributing that. SO FAR: see http://754r.ucbtest.org/background
RetroSearch is an open source project built by @garambo
| Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4