<div class="socmaildefaultfont" dir="ltr" style="font-family:Arial, Helvetica, sans-serif;font-size:10pt" ><div dir="ltr" ><div><font size="2" > <strong>Attendees</strong>: Rajan, Jim, Damian, Fred, Mike, Ian, David O., David H.</font><br> </div>
<div><font size="2" ><strong> New agenda items (https://wiki.edg.com/pub/CFP/WebHome/CFP_meeting_agenda_20210929-update2.pdf):</strong><br> None</font></div>
<div> </div>
<div><font size="2" ><strong> Carry-over action items:</strong><br> None</font></div>
<div> </div>
<div><font size="2" ><strong> Last meeting action items </strong>(done unless specified otherwise, details below)<strong>:</strong><br> Jim: Update N2746 with CFP 2090.<br> Fred: Send CFP 2094 to WG14.<br> Rajan: Ensure the C/C++ study group presentation sees P1467r4.<br> Rajan: Draft words for making freestanding support for CFP for both options in CFP2085.<br> Jim: Send CFP2089 as an update to N2672 barring any issues from this group.<br> All: Look over CFP2096 and give feedback within 2 weeks.</font></div>
<div> </div>
<div><font size="2" ><strong> New action items:</strong><br> Jim: Propose new wording for N2716's change that WG14 did not accept as is.<br> Rajan: Get a document number for CFP2140 and send an updated document to CFP before WG14.<br> Jim: Put the formulas into CFP2130's text and show CFP before submitting it to WG14.<br> Jim: Reword the footnote for CFP2153 and show it to CFP before submitting it to WG14.<br> Jim: Send out a change to CFP changing the wording of the FLT_MAX_EXP family of macros to say they are for normalized numbers.<br> Anyone: Look into the use of the term "floating-point number".<br> Rajan: Get back to Aaron about the FLT_EVAL_METHOD constant value question and point him to part 5 of the TS which does have changing values.<br> All: Look at CFP2136 and respond within a week.<br> Jim: Submit a paper to remove the promotion rules as per discussion in CFP2141.<br> Jim: Propose the change in CFP2154 to WG14.</font></div>
<div> </div>
<div><font size="2" ><strong> Next Meeting(s):</strong><br> CFP, C++ liaison, and C++ Numerics study groups:<br> October 6th, 2021.</font></div>
<div><font size="2" > See CFP2151 for details.</font></div>
<div> </div>
<div><font size="2" > CFP:<br> Same time slot.<br> Wednesday, October 13th, 2021, 3PM UTC<br> ISO Zoom teleconference<br> Please notify the group if this time slot does not work.</font></div>
<div> </div>
<div><font size="2" ><strong> WG14 meeting:</strong><br> See CFP 2128, 2129, 2131.<br> Jim to propose a response to WG14's request for different wording for the numerically equal paper along the lines of CFP2145.<br> <br><strong> C++ Liaison:</strong><br> CFP C23 changes summary page for the C++ liaison study group (See CFP 2060, 2142, 2147, 2151, 2157)<br> David O: Beyond CFP 2142, there is also implicit conversion that need to be looked at. C does conversions between any floating point types implicitly like other arithmetic types. C++ does not not. Lossy conversions have to be explicit.<br> Jim: We did change that, but it was not seen by WG14. Oversight on our part. It's later in the agenda. There is a reason why we do what we do for C. Is there a reason for C++?<br> David O: It matches what we do for the integer types.<br> Jim: The float type may not the same as _Float32 in C++, whereas in C, we prefer IEEE over non-IEEE.<br> David O: The biggest issue is the naming. In C they are optional keywords. In C++ they are typedefs in the std namespace.<br> Note: We do have the October 6th meeting with C++. See CFP2151 for detail.<br> <br><strong> C23 integration:</strong><br> Latest C2X drafts: <a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2596.pdf" >http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2596.pdf</a> <a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2573.pdf" >http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2573.pdf</a> <a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2478.pdf" >http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2478.pdf</a><br> IEC 60559:2020 support</font></div>
<div> </div>
<div><font size="2" ><strong> Action item resolutions:</strong><br> Jim: Overflow/Underflow definitions: Update N2746 with CFP 2090 (See CFP 2116, 2116, 2118, 2122, 2133)<br> Done.<br> <br> Fred: Send CFP2094 to WG14 (subnormal macros)<br> See N2797.</font></div>
<div> </div>
<div><font size="2" > Rajan: Ensure the C/C++ study group presentation sees P1467r4<br> Done.</font></div>
<div> </div>
<div><font size="2" > Rajan: Draft words for making freestanding support for CFP for both options in CFP2085 (CFP 2140, others)<br> Fred: The original errno requirement was from C89 for the strtod functions. We missed updating it in C99 to remove errno.<br> Jim: I see how freestanding does not want global state, but the second alternative still has it.<br> Rajan: Yes, the first alternative doesn't require either, while the second requires at least TLS or global state.<br> Fred: strtol has errno too. This should apply to it.<br> David O: I don't think this would be good for the next CFP/C++ meeting and Ben Craig is the one interested in this.<br> *AI*: Rajan: Get a document number for CFP2140 and send an updated document to CFP before WG14.<br> Fred: The strtol is a numeric conversion function that refers to errno. Perhaps we should say floating point numeric conversion functions to avoid adding strtol in the list.<br> Rajan: I can name the functions instead of saying floating point numeric conversion functions.<br> Jim: I prefer naming the functions. Or both.</font></div>
<div> </div>
<div><font size="2" > Jim: Send CFP2089 as an update to N2672 barring any issues from this group (See CFP 2112-2114, 2117, 2119, 2132, ...)<br> Looks good.</font></div>
<div> </div>
<div><font size="2" > All: Look over CFP2096 and give feedback within 2 weeks (See CFP 2105, ...)<br> Jim: Better to make the change in 7.12 instead of the floating point model in 5.2.4.2.2.<br> Mike: I like CFP2134, but I get your point about it not being usual for C standard readers. For decimal we don't normalize at all so it doesn't make sense. For binary it does.<br> Jim: I argue it does for both binary and decimal.<br> Mike: The first paragraph works for both. You can clarify it for binary users by saying how normalizing refers to normal. There is no normalizing concept for decimal. "Minimum normalized floating-point number" means nothing in decimal.<br> Jim: It is the one with the minimum exponent in the cohort. A leading non-zero digit in the model in 5.2.4.2.2. That translates into a full co-efficient.<br> Mike: If that is true, that is unfortunate for decimal. It is better if you have a clear formula and definition in one place. I would argue having both paragraphs there is better. i.e "in other words" to join the two definitions.<br> Rajan: Not normally good to have two definitions in case of disagreements between the two.<br> Mike: Perhaps put one as a footnote.<br> Jim: Perhaps put the formula in there (in parenthesis). Or vice versa.<br> Fred: The DFP definition uses the word normalized.<br> Mike: That slipped by me.<br> Ian: I prefer the formula first.<br> *AI*: Jim: Put the formulas into CFP2130's text and show CFP before submitting it to WG14.</font></div>
<div> </div>
<div><font size="2" ><strong> Other issues:</strong><br> Underflow with exact subnormal (See CFP 2106, ..., 2172)<br> Fred: For F.9.2 for DFP the transformations wouldn't work as being equivalent.<br> Jim: The beginning of the section qualifies this so we should be OK.<br> Ian: CFP2158 is what I implemented in the IBM compilers.<br> Looks good.<br> Jim: CFP2153.<br> Fred: I don't see how this would cause a difference for 1*x.<br> Jim: 1*x would get the precision of x shortened.<br> Jim: The notes are supposed to be guidance and not complete coverage.<br> Rajan: Agree. We can't cover every case.<br> Fred: Me too.<br> Jim: Anyone thing we should delete the dynamic rounding precision part?<br> Rajan: Can add in a "for example" at the beginning or later to make it clearer. It is fine how it is now for my reading.<br> Jim: Will look into doing a change and send it out for a quick email poll.<br> <br> Supernormal numbers (See CFP N2138, ...)<br> Jim: The underlying problem is we're not consistent what we mean by floating point number. Sometimes it is a model number, other times it is a number in a floating point type.<br> Rajan: Vicents change does make more English obvious what MAX refers to. I am actually OK with and prefer the change to add "normalized" to the macro descriptions.<br> *AI*: Jim: Send out a change to CFP changing the wording of the FLT_MAX_EXP family of macros to say they are for normalized numbers.<br> David H: I think trying to specify all the types of numbers and types is risky business.<br> Jim: Specifying the arithmetic of model numbers was what C wanted to do but then tried to generalize it to allow double-double and other arithmetic. Unfortunately we're in between those two approaches at this point.<br> Jim: It would be interesting to go through the 21 instances of floating-point number and see which meaning they have.<br> *AI*: Anyone: Look into the use of the term "floating-point number".</font></div>
<div> </div>
<div><font size="2" > Floating-point numbers (See CFP 2110)<br> </font></div>
<div><font size="2" > FP_NAN (See CFP 2120, ...)<br> Rajan: IBM's compiler defines these for HEX float formats for C99 and up.<br> Fred: OK with doing nothing here.<br> <br> FLT_EVAL_METHOD (See CFP 2126, 2127)<br> Jim: Perhaps pass a reference to part 5 which shows changing values for FLT_EVAL_METHOD based on block scope pragmas.<br> *AI*: Rajan: Get back to Aaron about the FLT_EVAL_METHOD constant value question and point him to part 5 of the TS which does have changing values.</font></div>
<div> </div>
<div><font size="2" > Tgmath.h narrowing macros with integer arguments (See CFP 2136)<br> *AI*: All: Look at CFP2136 and respond within a week.</font></div>
<div> </div>
<div><font size="2" > Intended removal of promotions in Part 3 (See CFP 2139, 2141)<br> David O: This is not the issue I raised. My issue was _Float64->_Float32 can be done implicitly in C. In C++ it can't.<br> Jim: Anything C++ wants here?<br> David O: Nothing. There is a difference, but that is something that we need to live with. It is an education issue, not a technical issue. We are OK with only float->double promotions.<br> *AI*: Jim: Submit a paper to remove the promotion rules as per discussion in CFP2141.<br> <br> feraiseexcept update (See CFP 2154)<br> David H, Ian: Looks good.<br> *AI*: Jim: Propose the change in CFP2154 to WG14.<br> </font></div></div></div><BR>
<BR>