754R Minutes - 2015 October 16 Recorded by David Hough The second meeting of the 754R revision group was a teleconference on 16 October 2015, convened at 8:00am and adjourned at 10:00am Pacific Daylight Time. Teleconference participants: David Chen Mike Cowlishaw Jim Demmel Ken Dockser Warren Ferguson David Gay Michel Hack David Hough W. Kahan Baker Kearfott David Lutz Terje Mathisen Jason Riedy Eric Schwarz Leonard Tsai Jim Thomas 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, surprising considering the animated discussions of technical matters that followed. Meetings: The next meetings will be held on November 13 and December 11. from 8:00 AM to 10:00 AM Silicon Valley time, which will be UT-8 in November and December. Website: The website 754r.ucbtest.org, left over from the previous effort, is being used for the time being. ===== We examined the editor's draft 201 incorporating the decisions of the previous meeting. * 6.2.1 and 6.2.2 - discussed whether the NaN specification applied to non-interchange formats and decided it did not, and so left the "interchange formats" decided at the last meeting in place. ===== Most of our effort was spent examining items on the Editor's Errata list: http://speleotrove.com/misc/IEEE754-errata.html that were not decided previously. * 4.3.1 - discussed whether the definition of roundTiesToEven should be made unambiguous when precision is 1 and thus the smallest significand in a binade or decade is "1", which is odd like its smaller neighbor, rather than even as in higher radices like "10". This matters for short decimal output representing normal binary formats: converting binary 9.5 to one significant figure E format, one has to choose between odd 9E0 and odd 1E1. So we accepted the proposed correction to round to the larger. We deferred discussion of the larger question of what the standard should say about very low-precision formats - see below. * 5.3.3 and elsewhere - sometimes it's ambiguous whether the text is referring to a mathematical function floor(x), sometimes represented with brackets, or a standard-defined operation in functional notation. floor, ceiling, min, max, and log all have ambiguous references of this sort. The correct conclusion can usually be drawn from context, but why risk an incorrect one? There are various typographic conventions that could be used - different fonts or in some cases like floor, mathematical symbols. However these are lost when one cuts and pastes from the formatted text to plain ascii. Another option is to use atan for a mathematical function and Atan for a standardized operation whenever the names would otherwise coincide. That allows cut and paste but either involves massive changes to the document or implies changing the names only of the colliding operations, a source of potential confusion. Mike had written about this several days ago - not all of us had read it: During the September 22 meeting, I took an informal action item to look into the use of bold (bold case font) in section 9.2. It turns out (with thanks to Jim Thomas for also looking into this) that the older parts of the document quite consistently use bold for operations defined by the standard (and do not use emphasis for mathematical functions). Starting in section 5.10 (where 'predicate' is used instead of 'operation') things become less consistent; for example, 'totalOrder' is introduced in bold but is thereafter unemphasised. Similarly, in sections 6 and 7 there are frequent references to operations without the use of bold. In section 9.2, the operations are emphasised in Table 9.1, but not in the text following and in 9.2.1. There are a few cases later in the document, too (10.4 and 11). There is a substantial amount of work to proof-read the existing document and ensure all operations are bold; however it seems straightforward and I am happy to do this if the committee so wishes (I would need guidance as to whether predicates should also be in bold). ***** ACTION ITEM for anybody interested: Considering the editorial effort to make large changes and the chances for error therein, along with the other considerations above, what's the best way to differentiate mathematical functions from standardized operations in the standard text? * 9.2 - what about asinPi, acosPI, and tanPi? We decided not to add tanPi - it would be an addition to the standard, with problems defining the signs of its poles. We decided to complete the definition of asinPi and acosPi by adding it to Table 9.1 and list special values in 9.2.1. ***** ACTION ITEM for Jim and Michel: Determine what is needed to complete the definition and inform Mike. ===== We went on to issues raised at the previous meeting and in email: * pow special cases - it's not clear whether we would be better off with a compact description of the special cases with a few rules, or with an exhaustive listing of everything that anybody could wonder about. There are precedents in several directions. However nobody at the meeting today had a specific proposal for change. ***** ACTION ITEM for anybody interested: Determine whether a change is warranted and propose something specific. * 9.2 - "functions" vs "operations - Mike noticed some inconsistent use of "functions" when we meant "operations". ***** ACTION ITEM for Mike: Change those uses to "operations". * 9.2 - "symmetric" and "anti-symmetric" were used just once to mean "even" and "odd". Agreed to use the better-known terminology. ***** ACTION ITEM for Mike: Change accordingly. * 3.7 Minimum precision of non-interchange functions. The seven interchange formats are defined with minimum 11 significant binary bits or 7 significant decimal digits. The other standardized formats are extended precision formats and extendable precision formats. The wording of 3.7 is clear that extended precision formats have wider precision and range than the smallest basic format (did we mean smallest interchange format?) It's not clear that the variable-precision extendable-precision formats are similarly constrained although the first sentence of 3.7 suggests that. Prof. Kahan pointed out that the proofs of theorems about arithmetic like Harry Diamond's break down with very narrow formats, probably because the theorems are false. The odd case of roundTiesToEven with one significant figure, mentioned above, is one example; automatic theorem-proving regimes like to have some axioms about computer arithmetic that they can rely on, so the standard should discourage formats that aren't reliable enough. Do we need to say more? ***** ACTION ITEM for anybody interested: Draft additional wording to discourage extendable-precision formats from getting too narrow. * Introduction - what's the goal? Hough proposed that the non-normative Introduction in the front matter be more explicit about the audience of the standard. An arithmetic standard is of little value to the mathematical software community unless its features are incorporated into language standards and those standards are implemented in compilers for most platforms of interest to users of mathematical software (e.g. Big Data analysts). So the arithmetic standard can be thought of as a meta-standard for language standards. Related to this is the matter of options. Throughout the arithmetic standard one finds choices in how to conform. Who gets to choose? Consistent with the above, one thinks of these choices as being made by language standards to fit the needs of a particular language user community, rather than by hardware implementors or compiler implementors or operating system implementors. Although nobody expects Python and Fortran to offer exactly analogous numerical features, many are troubled by the arithmetic variability in different implementations of the same language standard - that makes the job of the mathematical software developer and the automatic verification engine much more difficult. Even though the foregoing point of view would only be explicit in the non-normative Introduction, some users of the standard might view it as a substantive change from 2008. ***** ACTION ITEM for anybody interested: Think about the foregoing - how much do you agree with it? - and write up some proposed wording to express your viewpoint. * David Gay submitted comments by email. As adjournment was nigh, we decided to address these at the next meeting: On p. 17, two lines after the heading "5.1 Overview", "return" should be changed to "returns", to agree with the sentence's subject ("Each"). I suggest changing some of the wording on p. 47 to make the text clearer and more consistent. I would change lines 13-15 to Otherwise, an intermediate result is computed as though the exponent range were unbounded, and the final result is determined from the intermediate result in accordance with 7.4 and 7.5, which might signal overflow or underflow. I would make the same change to lines 17-19, starting with "Otherwise, sums are computed" on line 17. I would change line 23 to scaledProd(p,n) = (pr, sf), where p is a vector of length n and scaleB(pr, sf) is an implementation- line 26 to scaledProdSum(p, q, n) = (pr, sf), where p and q are vectors of length n and scaleB(pr, sf) is an and line 29 to scaledProdDiff(p, q, n) = (pr, sf), where p and q are vectors of length n and scaleB(pr, sf) is an with suitable use of fonts.