Editorial 28 5.4.1 3 The formatOf-based formulation of 5.4.1 for arithmetic operations should make manifest that part which is familiar to conventional programming languages and that part which is unfamiliar. Most languages have generic arithmetic operations +-*/. Most languages do not require an underlying implementation to directly support any combination of operand formats rounded only once to any narrower or wider format, yet that is what 5.4.1 requires. This is not a hardware issue at all; there are many possible hardware implementations. The issue is strictly a matter of good exposition to an audience of programming language designers. It's better to match the requirements of 754R and languages: define homogeneous 754R arithmetic operations that correspond to familiar language generic operators like +-*/, and define 754R narrowing operations that encapsulate the new capabilities that languages are required to provide. There are other reduced subsets of formatOf operations that can be composed to provide all the required variants, but these are closest to existing language structures. See http://754r.ucbtest.org/msc-ballots/formatof.pdf Yes Technical 40 5.12.3 15 5.12 and 5.12.3 specify different requirements for conversions between binary formats and hex character sequences. Implementations shall provide, but languages should provide. That's rather out of sync with the rest of clause 5. And since hex character sequences are intended to promote exact interchange of data among systems, it's not very useful if the required interfaces are implementation-defined. As with every other feature of 754R, language-defined is better than implementation-defined. Change "Language standards should provide" to "Language standards shall provide," which will have the same sense as elsewhere in 754R, that a language silent on some point defers it to implementation. Or alternately, be consistent in clause 5 that languages and implementations should provide the hex character sequences. YES Technical 50 9.2.1 1 sin/cos/tan/asin/acos/atan/atan2 are specified, but only sinPi/cosPi/atanPi/atan2Pi. Either tan/asin/acos should be omitted or tanPi/asinPi/acosPi should be added. Whatever the merit of any particular direct or inverse trigonometric function, it's the same regardless of how angles are measured. Less than full correspondence with the radian functions undermines the point of adding the trigPi functions. remove tan and add asinPi and acosPi. Special cases of asinPi and acosPi are the same as for asin and acos. If instead it were desired to retain tan and add tanPi, its special cases can be derived as quotients of sinPi/cosPi: of sinPi/cosPi: tanpi(+-0) is +-0; for n.gt.0, tanpi(2n) is +0, tanpi(2n-1) is -0; for n.lt.0 tanpi(2n) is -0, tanpi(2n+1) is +0, reflecting the oddness of tanPi; for n.gt.0, tanpi(2n-3/2) is +inf, tanpi(2n-1/2) is -inf; for n.lt.0, tanpi(2n+3/2) is -inf, tanpi(2n+1/2) is +inf. YES Editorial 55 10 3 Clause 10 has been repeatedly patched until it says almost the same things slightly differently in various places, and does so in an order that unfolds with less than mathematical logic. Clause 11 then revisits many of the same issues, from a slightly different perspective. Neither clause has attracted enough critical review because both are optional. Both need a coordinated rewrite, which does not fundamentally change the recommendation. If nobody bothers to understand and implemement the far-from-orthogonal concepts about expression evaluation rules, literal meaning, preferredWidth, optimization, and reproducibility, then 754R has failed to address 754 users' most serious issue: after 30 years nobody can be sure what z = x + y will be. What good is that kind of standard? See http://754r.ucbtest.org/msc-ballots/clause10.pdf Yes