<html><body><p><font size="2" face="sans-serif">Hi,</font><br><br><font size="2" face="sans-serif">Here is a raw summary of the floating point papers that were presented yesterday. I didn't get a chance to write down most of my responses to the questions as I was presenting and talking at the time, but the questions should have been mostly captured. The official WG14 minutes should capture my responses.</font><br><br><font size="2" face="sans-serif"><b>Action items for CFP:</b></font><br><font size="2" face="sans-serif"> All papers that had double-double concerns: Any new papers to handle the double-double concerns should have a line at the top saying that the main change was already voted into C23 and that this is a refinement to allow other cases.</font><br><font size="2" face="sans-serif"> N2806: Cleanup of 5.2.4.2.2: Split paragraph 4 into separate paragraphs for each category of numbers if it is complicated. Leave it to the editors (and notify them) if it is trivial.</font><br><font size="2" face="sans-serif"> N2848: INFINITY macro contradiction: Look into the math.h and float.h INFINITY macro definitions to ensure they are the same. If they are different and not trivial to word the same, write a paper, otherwise let the editors know so they can make any change needed.</font><br><font size="2" face="sans-serif"> N2823: CFP freestanding: Want another version of this paper with more motivation/rationale.</font><br><font size="2" face="sans-serif"> N2823: CFP freestanding: Want new paper(s) for the strtod* changes for BFP and Annex X as well. Note: It would be good to have 7.12.1#7 with matherrhandling & matherrno has a value 0 case considered as well.</font><br><br><font size="2" face="sans-serif"><b>Papers:</b></font><br><font size="2" face="sans-serif">5.9 Thomas, C23 proposal - 5.2.4.2.2 cleanup (N2672 update) [N 2806]</font><br><font size="2" face="sans-serif"> Straw poll: Put N2806 into C23?</font><br><font size="2" face="sans-serif"> 14/0/3. Consensus.</font><br><font size="2" face="sans-serif"> Straw poll: Does WG14 want to split paragraph 4 into separate categories editorially?</font><br><font size="2" face="sans-serif"> 7/1/9. Consensus. ^CFP: Can do this for C23. Or editorial if simple enough.</font><br><font size="2" face="sans-serif"> </font><br><font size="2" face="sans-serif">5.10 Thomas, C23 proposal - overflow and underflow definitions (N2746 update) [N 2805]</font><br><font size="2" face="sans-serif"> Jens: Difficult to understand "ordinary accuracy"? It needs a definition, not a footnote.</font><br><font size="2" face="sans-serif"> Uecker: Similar comment to Jens, like incremental improvements. Does C guarantee anything with rounding. Any guarantees in the FP world?</font><br><font size="2" face="sans-serif"> Fred: Implementation defined for accuracy in C FP.</font><br><font size="2" face="sans-serif"> Uecker: This should refer back to the clause for ordinary accuracy.</font><br><font size="2" face="sans-serif"> Joseph: Ordinary accuracy may be try to cover many different things... approx by the implementation, approx by the math result, unbounded exp for IEEE.</font><br><font size="2" face="sans-serif"> Joseph: For double double, the lower half variant has the result is the high half with distiguous bits. This means the normalized numbers need to be changed. For the other variant you do have lower precision, so you need supernormal numbers and change overflow so you don't give HUGE_VAL instead of supernormal values. There is also the POSIX one with variable precision with the supernormal numbers.</font><br><font size="2" face="sans-serif"> Jens: Seeing Josephs comment about 5.2.4.2.2p8 with the definition of accuracy. We should be clear about what the implementation needs to document. Need to define accuracy better.</font><br><font size="2" face="sans-serif"> Ballman: There are papers for overflow for integers on Friday. I would like to have something together for both instead of two definitions.</font><br><font size="2" face="sans-serif"> Keaton: Historically the standard (outside of Annex F), never gave any info on accuracy. It is a completely different topic than this. It is a completely different paper.</font><br><font size="2" face="sans-serif"> Joseph: Re defining accuracy. Depends a lot on the operation. Especially library. Ex. cpow.</font><br><font size="2" face="sans-serif"> Uecker: I get the point. Can we editorially change the footnote to point to the reference that Joseph gave.</font><br><font size="2" face="sans-serif"> </font><br><font size="2" face="sans-serif"> Straw poll: Put N2805 into C23?</font><br><font size="2" face="sans-serif"> 10/1/5. Consensus. Goes into C23.</font><br><br><font size="2" face="sans-serif">5.11 Thomas, C23 proposal - Annex F overflow and underflow [N 2747] </font><br><font size="2" face="sans-serif"> Philipp: We just voted in the previous definition in the base C standard. Why don't we point to that instead of what is here re tiny.</font><br><font size="2" face="sans-serif"> </font><br><font size="2" face="sans-serif"> Straw poll: Put C2747 into C23?</font><br><font size="2" face="sans-serif"> 12/0/5. Goes into C23.</font><br><font size="2" face="sans-serif"> </font><br><font size="2" face="sans-serif">5.12 Thomas, C23 proposal - Normal and subnormal classification [N 2842] </font><br><font size="2" face="sans-serif"> Joseph: Does this fit with the current existing macros like for DFP.</font><br><font size="2" face="sans-serif"> Fred: No problems with existing implementations.</font><br><font size="2" face="sans-serif"> Jens: I understand this definition better than overflow/underflow. Can we do underflow/overflow like this definition?</font><br><font size="2" face="sans-serif"> Fred: Rounding changes this and that's why this is different.</font><br><font size="2" face="sans-serif"> Alex: You mentioned incremental vs Big Bang. I like incremental changes that objective improvements with no drawbacks. This massively improves comprehensively of this.</font><br><font size="2" face="sans-serif"> </font><br><font size="2" face="sans-serif"> Straw poll: Put N2842 into C23?</font><br><font size="2" face="sans-serif"> 17/0/2. Goes into C23.</font><br><br><font size="2" face="sans-serif">5.13 Thomas, C23 proposal - Clarification for max exponent macros [N 2843]</font><br><font size="2" face="sans-serif"> Straw poll: Put N2843 into C23?</font><br><font size="2" face="sans-serif"> 16/0/2. Goes into C23.</font><br><br><font size="2" face="sans-serif"> ^CFP: Say any refinements are refinements of paper X that was already voted into C23 for all new papers brought forward by CFP that are refinements like requested for double-double for this paper.</font><br><br><font size="2" face="sans-serif">5.14 Tydeman, remquo() [N 2790] </font><br><font size="2" face="sans-serif"> Straw poll: Put N2790 into C23?</font><br><font size="2" face="sans-serif"> 15/0/5. Goes into C23.</font><br><br><font size="2" face="sans-serif">5.43: N2797 (Tydeman) *_HAS_SUBNORM==0 implies what?</font><br><font size="2" face="sans-serif"> Joseph: These macros were added in C11. No obsolescence. We shouldn't remove them without it. They may not cover all possible cases, but doesn't mean they are useless. Any C++ liaison issues?</font><br><font size="2" face="sans-serif"> Fred: I don't know of any C++ issues, but did remove 'gets' without any obsolescence.</font><br><font size="2" face="sans-serif"> Jens: Removing macros can invalidate code. Needs more investigation.</font><br><font size="2" face="sans-serif"> Rajan: Not good to remove without a replacement.</font><br><font size="2" face="sans-serif"> Alex: A user asking this implies it is in use.</font><br><font size="2" face="sans-serif"> Fred: The user was an implementor who wants to know how to define them. His answer was -1.</font><br><font size="2" face="sans-serif"> Ballman: Joseph asked if this is a liaison issue. It is. C++ defines this in the cfloat header.</font><br><font size="2" face="sans-serif"> Keaton: Can someone from CFP go to the C++ liaison group.</font><br><font size="2" face="sans-serif"> Fred: The absence of the macros is not painful. Easy to find out at runtime.</font><br><font size="2" face="sans-serif"> Jens: We need an action item on this. Not just liaison.</font><br><font size="2" face="sans-serif"> </font><br><font size="2" face="sans-serif">5.44: N2823 (Bhakta) CFP freestanding.</font><br><font size="2" face="sans-serif"> Philipp: This is only for IEEE conformance with freestanding. No threads means errno is global. Removing something from IEEE conformance is not good.</font><br><font size="2" face="sans-serif"> Bachmann: Having subnormals in IEEE is not optional. Having a function to allow access is very minor so I doubt it makes sense to have it. It seems unbalanced. N2095 says decimal floating point is not optional and small systems would have issues with that.</font><br><font size="2" face="sans-serif"> Fred: The changes to strtod is independent of freestanding and should be done anyways. I want both alternatives.</font><br><font size="2" face="sans-serif"> Banham: Is there an assumption that freestanding is not threaded. Smaller processes uses autos'(?) but not threads as in C.</font><br><font size="2" face="sans-serif"> Jens: I have difficulties with this paper. Didn't have time to prepare. It lacks rationale and description. Need more motivation. The changes are not worked out in the diff form. I want to see the original text as well as the changes.</font><br><font size="2" face="sans-serif"> Joseph: For alternative 1, the list of the functions excludes strfrom. Why?</font><br><font size="2" face="sans-serif"> Rajan: To avoid localization.</font><br><font size="2" face="sans-serif"> Banham: Seems to go too far for alternative 1. Removing the hardware modes is hard. It should be optional for exception handling.</font><br><font size="2" face="sans-serif"> </font><br><font size="2" face="sans-serif"> Straw poll: Does WG14 want N2823 alternative 1 in C23?</font><br><font size="2" face="sans-serif"> 5/3/10. No consensus.</font><br><font size="2" face="sans-serif"> Straw poll: Does WG14 want N2823 alternative 2 in C23?</font><br><font size="2" face="sans-serif"> 4/4/10. No consensus.</font><br><font size="2" face="sans-serif"> Straw poll: Does WG14 want N2823 change 7.22.1.6#7 in alternative 2 in C23?</font><br><font size="2" face="sans-serif"> 9/1/9. Goes into C23.</font><br><br><font size="2" face="sans-serif"> Joseph: The strtod is only for DFP, not BFP and Annex X. Do you want to change those too?</font><br><font size="2" face="sans-serif"> Rajan: I can write those papers if this is accepted.</font><br><font size="2" face="sans-serif"> Philipp: I am uncomfortable to change them for decimal.</font><br><font size="2" face="sans-serif"> Jens: Another paper will be good. I need a rationale though.</font><br><font size="2" face="sans-serif"> Joseph: For the future papers for the strto functions, it would be good to have 7.12.1#7 with matherrhandling & matherrno has a value 0.</font><br><br><font size="2" face="sans-serif"> Straw poll: Does WG14 want something along the lines of N2823 in C23?</font><br><font size="2" face="sans-serif"> 9/2/7. Consensus.</font><br><font size="2" face="sans-serif"> </font><br><font size="2" face="sans-serif"> Ballman: Need the rationale and the existing wording as well as time to prepare for this paper.</font><br><font size="2" face="sans-serif"> Joseph: We could schedule more than 6 papers for a floating point day.</font><br><font size="2" face="sans-serif"> Ballman: For the future, CFP is small and targeted so it may be better to have an omnibus paper. We'd only schedule 1 paper instead of 6.</font><br><font size="2" face="sans-serif"> Keaton: The committee always found it easier to approve small pieces rather than unrelated single papers.</font><br><font size="2" face="sans-serif"> Ballman: WG21 does that for issues.</font><br><font size="2" face="sans-serif"> Jens: We could have an informal check of wording before things go in?</font><br><br><font size="2" face="sans-serif">5.45: N2845</font><br><font size="2" face="sans-serif"> Straw poll: Put N2845 into C23?</font><br><font size="2" face="sans-serif"> 17/0/1. Goes into C23.</font><br><br><font size="2" face="sans-serif">5.46: N2846: Transformation expressions</font><br><font size="2" face="sans-serif"> Jens: Non-required -> extensions or optional features</font><br><font size="2" face="sans-serif"> Fred: SNaNs are part of the main text in the standard.</font><br><font size="2" face="sans-serif"> </font><br><font size="2" face="sans-serif"> Straw poll: Put N2846 into C23?</font><br><font size="2" face="sans-serif"> 18/0/2. Goes into C23.</font><br><br><font size="2" face="sans-serif">5.47: N2848: Infinity macro contradiction</font><br><font size="2" face="sans-serif"> Joseph: Only float.h change not math.h? Deliberate?</font><br><font size="2" face="sans-serif"> Fred: Didn't we move them?</font><br><font size="2" face="sans-serif"> Joseph: We copied these and math.h is obsolescent.</font><br><font size="2" face="sans-serif"> Banham: Can't you just have a float constant? #.f the is Infinity.</font><br><font size="2" face="sans-serif"> Jens: Like something along the lines of this. This is a normative change. It can invalidate existing programs.</font><br><font size="2" face="sans-serif"> Philipp: The suggested change is fine. Someone may want INFINITY vs HUGE_VAL, but that is not a good case. They should have used HUGE_VAL. Infinity as a feature test macro is useful.</font><br><font size="2" face="sans-serif"> Joseph: Re: Application code would have used math.h vs float.h so it could be good to have that difference.</font><br><font size="2" face="sans-serif"> Jens: Please don't. Not a good idea to have different definitions in two places.</font><br><font size="2" face="sans-serif"> Philipp: I agree. The suggested change should be made for all INFINITY definitions, not just one.</font><br><font size="2" face="sans-serif"> </font><br><font size="2" face="sans-serif"> Straw poll: Put the suggested change in N2848 into C23?</font><br><font size="2" face="sans-serif"> 19/1/0. Goes into C23.</font><br><font size="2" face="sans-serif"> Straw poll: Does WG14 want both definitions of INFINITY to match the float.h definition?</font><br><font size="2" face="sans-serif"> 18/0/0. Clear sentiment.</font><br><br><font size="2" face="sans-serif"> ^CFP Look into the math.h and float.h INFINITY macro definition to ensure they are the same.</font><br><br><br><font size="2" face="sans-serif">Regards,<br><br></font><font size="2" face="sans-serif"><b>Rajan Bhakta</b></font><font size="2" face="sans-serif"><br>z/OS XL C/C++ Compiler Technical Architect<br>ISO C Standards Representative (Canada, USA), PL22.11 Chair<br>C/C++ Compiler Development</font><br><font size="2" face="sans-serif">rbhakta@us.ibm.com</font><br><br><font size="2" face="sans-serif">IBM</font><BR>
<BR>
</body></html>