<html><body><p><font size="2" face="sans-serif"> </font><font size="2" face="sans-serif"><b>Attendees</b></font><font size="2" face="sans-serif">: Rajan, Jim, Fred, Mike, Ian, Damian, David H,</font><br><br><font size="2" face="sans-serif"> </font><font size="2" face="sans-serif"><b>New agenda items</b></font><font size="2" face="sans-serif"> (</font><a href="https://wiki.edg.com/pub/CFP/WebHome/CFP_meeting_agenda_20211123-update2.pdf"><font size="2" face="sans-serif">https://wiki.edg.com/pub/CFP/WebHome/CFP_meeting_agenda_20211123-update2.pdf</font></a><font size="2" face="sans-serif">):</font><br><font size="2" face="sans-serif"> None</font><br><br><font size="2" face="sans-serif"><b> Carry-over action items:</b></font><br><font size="2" face="sans-serif"> None</font><br><br><font size="2" face="sans-serif"><b> Last meeting action items (done unless specified otherwise, details below):</b></font><br><font size="2" face="sans-serif"> Jim: Update the INFINITY macro paper to define INFINITY iff infinities exist in type float, and as an alternative, do what is in the current paper.</font><br><font size="2" face="sans-serif"> Rajan: Bring up CFP's position in WG14's liaison report on not proposing double and long double INFINITY macros despite it being brought up. If WG14 wants it, let us (CFP) know.</font><br><font size="2" face="sans-serif"> Jim: Change N2716's alternative wording proposal to replace the second "=" in the example with "yields" and the "page 450" with the section, sub-clause number.</font><br><font size="2" face="sans-serif"> Jim: Look at the changed text and why some unintentional underlining is present in C23_proposal_-_Normal_and_subnormal_classification-20211008.pdf (Ex. emax).</font><br><br><font size="2" face="sans-serif"><b> New action items:</b></font><br><font size="2" face="sans-serif"> Jim: Write a note to the editor of WG14 to copy the definition of INIFINITY or make a pointer to the float.h definition in math.h. Also look at the other macros to see if there are others with the same issue.</font><br><font size="2" face="sans-serif"> Jim: Update CFP2277 linked documents to list November 2021 (not just November) for the WG14 meeting.</font><br><font size="2" face="sans-serif"> Jim: See what can be done to show the latest changes to existing accepted changes in all double-double updates to previously passed CFP papers.</font><br><font size="2" face="sans-serif"> Jim: Put 'model number' into the 5.2.4.2.2 classification paragraphs. Ex. Saying 'model floating point number x'.</font><br><font size="2" face="sans-serif"> Jim: Look at making zero's into a separate paragraph for 5.2.4.2.2 number categories.</font><br><font size="2" face="sans-serif"> Jim: Fix the pronouns (remove?) for the document in the second link in CFP2277 in the motivation section.</font><br><font size="2" face="sans-serif"> Rajan: For CFP2291, update the color to be more readable and add in wcstod functions updates and refer to overflow/underflow in 7.12.1 if possible.</font><br><font size="2" face="sans-serif"> Fred: Ask C++ what their issues with *_HAS_SUBNORM are and if they are OK with obsoleting it.</font><br><font size="2" face="sans-serif"> Jim: Add in "(finite or infinite)" to the last proposed change after "number" in CFP2280.</font><br><font size="2" face="sans-serif"> Jim: Consider nextafter for the changes in CFP2280.</font><br><font size="2" face="sans-serif"> Jim: Look to put CFP2280 into the overflow update.</font><br><br><font size="2" face="sans-serif"><b> Next Meeting(s):</b></font><br><font size="2" face="sans-serif"> Same time slot.</font><br><font size="2" face="sans-serif"> December 22nd, 2021, 4PM UTC</font><br><font size="2" face="sans-serif"> ISO Zoom teleconference</font><br><font size="2" face="sans-serif"> Please notify the group if this time slot does not work.</font><br><br><font size="2" face="sans-serif"><b> Upcoming WG14 meetings:</b></font><br><font size="2" face="sans-serif"> January 31-February 4, 2022, Portland, Oregon, US (Tentative)</font><br><font size="2" face="sans-serif"> Mailing deadline: December 31, 2021</font><br><font size="2" face="sans-serif"> July 11-15, 2022, Strasbourg, France (Tentative)</font><br><font size="2" face="sans-serif"> Mailing deadline: June 10, 2022</font><br><br><font size="2" face="sans-serif"><b> WG14 meeting report (CFP 2273):</b></font><br><font size="2" face="sans-serif"> N2797: Fred to write a new paper before doing anything else. Flush operands, etc.</font><br><font size="2" face="sans-serif"> Jim: We have a problematic definition here. Some implementation specific code may depend on this but not a pure portable one. Any consideration on obsolescence?</font><br><font size="2" face="sans-serif"> Rajan: Yes, some. Not sure if everyone agreed.</font><br><font size="2" face="sans-serif"> Jim: For C++ it seems we are supposed to ask if we can remove it.</font><br><font size="2" face="sans-serif"> Fred: Aaron said it won't make the next liaison meeting.</font><br><font size="2" face="sans-serif"> Jim: Any clarification about new proposals?</font><br><font size="2" face="sans-serif"> Fred: No new proposals, but can follow up existing proposals. My tgamma will not go into C23 so no rush on it.</font><br><br><font size="2" face="sans-serif"><b> C++ Liaison:</b></font><br><font size="2" face="sans-serif"> WG21's SC22 special meeting about C/C++ compatibility (See CFP2242/2243):</font><br><font size="2" face="sans-serif"> Ian: I agree with wanting long double + _Float64 -> long double. You'd lose information otherwise.</font><br><font size="2" face="sans-serif"> Jim: No, it wouldn't be the case. If long double is more precise, you get long double.</font><br><font size="2" face="sans-serif"> Ian: OK, makes sense. Then I'm fine.</font><br><font size="2" face="sans-serif"> No response from David Olsen. Leaving it as is assuming agreement or at least no contest.</font><br><br><font size="2" face="sans-serif"><b> C23 integration:</b></font><br><font size="2" face="sans-serif"> Latest C2X drafts: </font><a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2596.pdf"><font size="2" face="sans-serif">http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2596.pdf</font></a><font size="2" face="sans-serif"> </font><a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2573.pdf"><font size="2" face="sans-serif">http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2573.pdf</font></a><font size="2" face="sans-serif"> </font><a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2478.pdf"><font size="2" face="sans-serif">http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2478.pdf</font></a><br><font size="2" face="sans-serif"> New draft N2931 is up, but some issues with table of contents and other garbage characters. There will be a newer draft that fixes this.</font><br><br><font size="2" face="sans-serif"><b> Action item resolutions:</b></font><br><font size="2" face="sans-serif"> Jim: Update the INFINITY macro paper to define INFINITY iff infinities exist in type float, and as an alternative, do what is in the current paper (See N2848)</font><br><font size="2" face="sans-serif"> Jim: The change we had only addresses float.h. This should be able to be handled by a note to the editor to copy the definition or have a pointer in math.h to this definition.</font><br><font size="2" face="sans-serif"> ^Jim: Write a note to the editor of WG14 to copy the definition of INIFINITY or make a pointer to the float.h definition in math.h. Also look at the other macros to see if there are others with the same issue.</font><br><font size="2" face="sans-serif"> Fred: We may want to have a new paper to do all the macros with a pointer from math.h to float.h.</font><br><font size="2" face="sans-serif"> Jim: Some were not in C18 so we can just remove them.</font><br><br><font size="2" face="sans-serif"> Rajan: Bring up CFP's position in WG14's liaison report on not proposing double and long double INFINITY macros despite it being brought up. If WG14 wants it, let us (CFP) know.</font><br><font size="2" face="sans-serif"> No issue. WG14 did not ask for it.</font><br><br><font size="2" face="sans-serif"> Jim: Change N2716's alternative wording proposal to replace the second "=" in the example with "yields" and the "page 450" with the section, sub-clause number (See N2847)</font><br><font size="2" face="sans-serif"> Will be handled when WG14 looks at the paper.</font><br><br><font size="2" face="sans-serif"> Jim: Look at the changed text and why some unintentional underlining is present in C23_proposal_-_Normal_and_subnormal_classification-20211008.pdf (Ex. emax) (See N2842)</font><br><font size="2" face="sans-serif"> Jim: A double double update is present. Update coming.</font><br><font size="2" face="sans-serif"> </font><br><font size="2" face="sans-serif"><b> Other issues</b></font><br><font size="2" face="sans-serif"> Action items from WG14 meeting –5.2.4.2.2 clarification, double-double support (See CFP 2277, 2279, ... 2289)</font><br><font size="2" face="sans-serif"> ^Jim: Update CFP2277 linked documents to list November 2021 (not just November) for the WG14 meeting.</font><br><font size="2" face="sans-serif"> CFP2277: Update to N2806: Link 1:</font><br><font size="2" face="sans-serif"> Jim: The changes are cumulative, these are not only the change to what was already accepted. Need to look at how to just do the last change and not the changes to the changes.</font><br><font size="2" face="sans-serif"> Fred: We could do the before/after with the before being the accepted changes as regular text.</font><br><font size="2" face="sans-serif"> Rajan: Could just highlight the newest changes?</font><br><font size="2" face="sans-serif"> ^Jim: See what can be done to show the latest changes to existing accepted changes in all double-double updates to previously passed CFP papers.</font><br><font size="2" face="sans-serif"> Fred: Any way to change numbers to model numbers via italics or something? Confuses me all the time.</font><br><font size="2" face="sans-serif"> Jim: How about just saying "model numbers" instead? Or "Floating-point numbers x in the model"?</font><br><font size="2" face="sans-serif"> Fred: Yes, that would work.</font><br><font size="2" face="sans-serif"> ^Jim: Put 'model number' into the 5.2.4.2.2 classification paragraphs. Ex. Saying 'model floating point number x'.</font><br><font size="2" face="sans-serif"> David H: I like 'model floating point number x' </font><br><font size="2" face="sans-serif"> Fred: Do we want to cover double-double normalized numbers?</font><br><font size="2" face="sans-serif"> Jim: I don't know what that means, it's already there.</font><br><font size="2" face="sans-serif"> Fred: The strikeout of "f1 > 0 and all possible..." was the definition of the normalized numbers.</font><br><font size="2" face="sans-serif"> Jim: So 1+dbl_min is normalized?</font><br><font size="2" face="sans-serif"> Fred: No, it is not.</font><br><font size="2" face="sans-serif"> Jim: We're adding clarification, not changing the definition of normalized numbers.</font><br><font size="2" face="sans-serif"> Fred: For my change, see CFP2289.</font><br><font size="2" face="sans-serif"> David H: How much we have to say about the numbers outside the model?</font><br><font size="2" face="sans-serif"> Jim: We have the footnote that covers that. We don't want normative text for double-double since there is no standard for it.</font><br><font size="2" face="sans-serif"> David H: We can only standardize the double-double model numbers and leave the rest to their fate.</font><br><font size="2" face="sans-serif"> Fred: OK.</font><br><font size="2" face="sans-serif"> Jim: I also removed 'extra' because there are implementations that have extra range but less precision.</font><br><font size="2" face="sans-serif"> Fred: Do we need a separate paragraph for zero?</font><br><font size="2" face="sans-serif"> ^Jim: Look at making zero's into a separate paragraph for 5.2.4.2.2 number categories.</font><br><font size="2" face="sans-serif"> Fred: That can remove a lot of the text in #4.</font><br><font size="2" face="sans-serif"> Jim: No, the #3 paragraphs are definitions, no requirements so #4 stays as is.</font><br><br><font size="2" face="sans-serif"> Link 2: Overflow/underflow:</font><br><font size="2" face="sans-serif"> ^Jim: Fix the pronouns (remove?) for the document in the second link in CFP2277 in the motivation section.</font><br><font size="2" face="sans-serif"> Fred: One objection in the WG14 meeting was someone not understanding "ordinary accuracy".</font><br><font size="2" face="sans-serif"> Jim: Ordinary accuracy was what replaced "extraordinary roundoff error" which was equally vague.</font><br><font size="2" face="sans-serif"> Fred: The HUGE_VAL text is too strong a statement and the however clause in green doesn't override it.</font><br><font size="2" face="sans-serif"> Jim: I can see your point in one sense. We're really making an exception here. There is a change to HUGE_VAL in another topic which may effect this. I don't know which implementations do what. We need this exception for a very small number of exceptions.</font><br><font size="2" face="sans-serif"> Fred: Overflow doesn't mean over the largest normalized, correct?</font><br><font size="2" face="sans-serif"> Jim: Yes. Too large for representation with full precision.</font><br><font size="2" face="sans-serif"> Fred: GCC's double double have full precision for the largest number larger than the largest normalized.</font><br><font size="2" face="sans-serif"> Jim: Yes, that was Josephs specific request that those cases not overflow. I assume that's what those implementations would do, but I don't even know that.</font><br><font size="2" face="sans-serif"> Fred: I withdraw my comment about model numbers in the black text here. What is there is fine.</font><br><br><font size="2" face="sans-serif"> Link 3:</font><br><font size="2" face="sans-serif"> Fred: The "may" should be a "shall".</font><br><font size="2" face="sans-serif"> Jim: We have an accepted definition and we're trying to stretch it for a certain class of double-double implementations. They have a contiguous set of values with full precision up to that higher precision. The looseness of the specification makes me think "may" is better. Also the implementations may want to classify the values as something else which is allowed for numbers outside of the model.</font><br><font size="2" face="sans-serif"> Fred: Can be may/should/shall.</font><br><font size="2" face="sans-serif"> Ian: I am good with may.</font><br><font size="2" face="sans-serif"> Rajan: 'Shall' may have objections.</font><br><font size="2" face="sans-serif"> Fred: 'Should' can be used (recommended practice type).</font><br><font size="2" face="sans-serif"> Ian: I don't think double-double should be recommended practice.</font><br><font size="2" face="sans-serif"> Fred: I think if it has full precision it should be a normal number.</font><br><font size="2" face="sans-serif"> Leave it as 'may'.</font><br><br><font size="2" face="sans-serif"> Link 4: Max exponent macros</font><br><font size="2" face="sans-serif"> Looks good.</font><br><br><font size="2" face="sans-serif"> Action item from WG14 meeting – address INFINITY macro contradiction</font><br><font size="2" face="sans-serif"> Done above.</font><br><font size="2" face="sans-serif"> </font><br><font size="2" face="sans-serif"> Action item from WG14 meeting – revise N2823 (Freestanding + FP) (See CFP 2291)</font><br><font size="2" face="sans-serif"> Fred: Lime-green is unreadable. Needs to change.</font><br><font size="2" face="sans-serif"> Fred: wcstod also needs to be done. Maybe just refer to overflow/underflow as defined in math.h.</font><br><font size="2" face="sans-serif"> Jim: We need to make the overflow definition in math.h to be compatible with the strtod functions. If you can point to the other definition for overflow (7.12.1) which we talked about, it would be ideal. HUGE_VAL only matters for strtod and wcstod.</font><br><font size="2" face="sans-serif"> Rajan: I can update this and send it out as soon as I can.</font><br><font size="2" face="sans-serif"> ^Rajan: For CFP2291, update the color to be more readable and add in wcstod functions updates and refer to overflow/underflow in 7.12.1 if possible.</font><br><font size="2" face="sans-serif"> Jim: Don't try to expand this out.</font><br><font size="2" face="sans-serif"> Fred: atof has strtod being the same except for error conditions. We may need to expand it there.</font><br><font size="2" face="sans-serif"> Rajan: 7.22.1#1 says we don't need to worry about errno so no issue for this paper.</font><br><br><font size="2" face="sans-serif"> Action item from WG14 meeting – issues with N2797 (*_HAS_SUBNORM==0 implies what?)</font><br><font size="2" face="sans-serif"> Fred: Should be expanded to allow flushing operands or results independently.</font><br><font size="2" face="sans-serif"> Rajan: I think keeping the macro with new values (as independent/powers of 2) will be palatable for WG14.</font><br><font size="2" face="sans-serif"> Fred: Changing the behavior at runtime should require the value -1. This is beyond the standard.</font><br><font size="2" face="sans-serif"> Removed as an action item: Fred: Write a proposal for *_HAS_SUBNORM updates that allow independent flushing of operands or results as new values for the macro, and saying that changing the behavior at runtime should require value -1.</font><br><font size="2" face="sans-serif"> Jim: That is not my understanding on where we're going with this. I thought you were going to C++, and obsolesce it without change.</font><br><font size="2" face="sans-serif"> Fred: I wanted to give the liaison group the option of leave as is, obsolesce, remove immediately, or expand.</font><br><font size="2" face="sans-serif"> Jim: I don't know we're good with anything here beyond that.</font><br><font size="2" face="sans-serif"> ^Fred: Ask C++ what their issues with *_HAS_SUBNORM are and if they are OK with obsoleting it.</font><br><font size="2" face="sans-serif"> </font><br><font size="2" face="sans-serif"> Unordered (unmixable) types (See CFP 2244, 2250, 2251)</font><br><font size="2" face="sans-serif"> Leave as is.</font><br><font size="2" face="sans-serif"> Since Vincent is OK with leaving it as is, we will not propose anything new for post C23.</font><br><font size="2" face="sans-serif"> </font><br><font size="2" face="sans-serif"> HUGE_VAL (See CFP 2245's chain)</font><br><font size="2" face="sans-serif"> Jim: For nextup/nextdown we list HUGE_VAL. It is problematic. nextup/downup should step through representable values.</font><br><font size="2" face="sans-serif"> David H: Yes.</font><br><font size="2" face="sans-serif"> Fred: If there is no infinity, is nextup for the largest representable number, is there an overflow or not?</font><br><font size="2" face="sans-serif"> David H: No, it stays without signaling. It is as if it was an infinity.</font><br><font size="2" face="sans-serif"> Jim: For double double, it is representable values, not model numbers.</font><br><font size="2" face="sans-serif"> Fred: So nextup of 1 is the smallest denorm.</font><br><font size="2" face="sans-serif"> Fred: We could add in "(without overflow)" to the suggested text. Also, does 'number' include infinity?</font><br><font size="2" face="sans-serif"> Jim: Yes. My concern with overflow is I'm not sure if overflow is mentioned in that part of the standard. We talk about range errors.</font><br><font size="2" face="sans-serif"> Fred: We can say without a range error.</font><br><font size="2" face="sans-serif"> Jim: We don't say that either.</font><br><font size="2" face="sans-serif"> Jim: Is the '(finite or infinite)' helpful?</font><br><font size="2" face="sans-serif"> ^Jim: Add in "(finite or infinite)" to the last proposed change after "number" in CFP2280.</font><br><font size="2" face="sans-serif"> Rajan: Problem 1b's suggested fix: "llbrary" -> "library"</font><br><font size="2" face="sans-serif"> Fred: Can we just say HUGE_VAL is infinity if supported or the largest positive finite number and remove it from the library?</font><br><font size="2" face="sans-serif"> Jim: That wouldn't work for the double double case. Also that change would change the meaning of the macro from being the overflow result. It is not in float.h.</font><br><font size="2" face="sans-serif"> Fred: How about nextafter? Is that an issue?</font><br><font size="2" face="sans-serif"> Jim: We should do something there as well.</font><br><font size="2" face="sans-serif"> ^Jim: Consider nextafter for the changes in CFP2280.</font><br><font size="2" face="sans-serif"> Jim: These are tied to the overflow definitions so could get in there. The nextup/down could be considered editorial.</font><br><font size="2" face="sans-serif"> ^Jim: Look to put CFP2280 into the overflow update.</font><br><font size="2" face="sans-serif"> </font><br><font size="2" face="sans-serif"> Meaning of “nearest” in case of overflow (See CFP 2246, 2260)</font><br><font size="2" face="sans-serif"> Needs discussion.</font><br><font size="2" face="sans-serif"> Continue in next meeting.</font><br><font size="2" face="sans-serif"> </font><br><font size="2" face="sans-serif"> Overflow, normalized numbers, N2805 and N2806 (See CFP 2247, 2259 chains)</font><br><font size="2" face="sans-serif"> Covered already.</font><br><font size="2" face="sans-serif"> </font><br><font size="2" face="sans-serif"> printf and rounding recommendation (See CFP 2256 chain)</font><br><font size="2" face="sans-serif"> Jim: Leave as QoI?</font><br><font size="2" face="sans-serif"> Continue in next meeting.</font><br><font size="2" face="sans-serif"> </font><br><font size="2" face="sans-serif"> Terminology issues (See CFP 2258 chain)</font><br><font size="2" face="sans-serif"> Jim: Need proposal?</font><br><font size="2" face="sans-serif"> Continue in next meeting.</font><br><font size="2" face="sans-serif"> </font><br><font size="2" face="sans-serif"> Missing comma (See CFP 2266 chain)</font><br><font size="2" face="sans-serif"> Typo. Already sent to the editor.</font><br><font size="2" face="sans-serif"> </font><br><font size="2" face="sans-serif"> tgamma (See CFP 2274 chain)</font><br><font size="2" face="sans-serif"> Fred: New proposal.</font><br><font size="2" face="sans-serif"> </font><br><font size="2" face="sans-serif"><b> Others?</b></font><br><font size="2" face="sans-serif"> Jim: Fred, if you want to record things that are new proposals, that would be good.</font><br><font size="2" face="sans-serif"> Fred: OK.</font><BR>
<BR>
</body></html>