<font size=2 face="sans-serif"> Attendees: Rajan, Jim, David H,
Fred, Ian</font><br><br><font size=2 face="sans-serif"><b> New agenda items:</b></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"> Ian: See if there is an
incompatibility between C and C++ for constants being evaluated to a wider
format (Ex. FLT_EVAL_METHOD affects constants in C++, and wider return
values) - Keep open (Hubert: Not defined and left up to C)</font><br><font size=2 face="sans-serif"> Jim: Update the binding
table in parts 1 and 2 to handle the new IEEE-754:2018 functions when published.
- Keep open.</font><br><font size=2 face="sans-serif"> David: Check the min/max
C specification to ensure it matches what IEEE has. - Not done.</font><br><font size=2 face="sans-serif"> David: Check the augmented*
C function specifications to ensure they match what IEEE has. - Not done.</font><br><font size=2 face="sans-serif"> All: totalorder* differ
for NaN payloads: Note that we don’t have approval to move up to 754 201x
yet. - Keep open: Revisit after we move up to the 754 draft.</font><br><font size=2 face="sans-serif"> </font><br><font size=2 face="sans-serif"><b> Last meeting action items:</b></font><br><font size=2 face="sans-serif"> All: Consider the fact
that C doesn't support the SNaN sequence that IEEE does. Can have strtod
take it as input. - Done.</font><br><font size=2 face="sans-serif"> Rajan: Draft a paper on
macro vs function (pointer vs arguments) causing signalling asking for
recommendations from WG14 or ask if it is a problem for anyone. - Done.</font><br><font size=2 face="sans-serif"> Jim: Fix the sqrt and
rootn identity conflicts with IEEE. - Done.</font><br><font size=2 face="sans-serif"> Fred: Ensure pown matches
IEEE for the identity conflicts. - Done.</font><br><font size=2 face="sans-serif"> </font><br><font size=2 face="sans-serif"><b> New action items:</b></font><br><font size=2 face="sans-serif"> Fred: Ensure that the
items for P4_CR_for_rootn.pdf match IEEE.</font><br><font size=2 face="sans-serif"> Jim: Create a CR for Part
4 from P4_CR_for_rootn.pdf.</font><br><font size=2 face="sans-serif"> All: Consider the printf
for NaN(n-char-sequence) bounding issue.</font><br><br><font size=2 face="sans-serif"><b> Next Meeting(s):</b></font><br><font size=2 face="sans-serif"> Wednesday, November 28th,
2018, 11:00 EDT, 8:00 PST, 3PM UTC</font><br><font size=2 face="sans-serif"> Same teleconference number.</font><br><br><font size=2 face="sans-serif"><b> Discussion:</b></font><br><font size=2 face="sans-serif"> WG14 meeting: See Rajan's
emails on October 16/17:</font><br><font size=2 face="sans-serif"> Should the part
1 and 2 updates include the editorial changes?</font><br><font size=2 face="sans-serif"> Yes.</font><br><font size=2 face="sans-serif"> Part 3 should be
reworked into a conditionally normative annex to C2X.</font><br><font size=2 face="sans-serif"> For the SNAN parameter
issue, it was a general statement.</font><br><font size=2 face="sans-serif"> Jim: Was the optional
nature mentioned?</font><br><font size=2 face="sans-serif"> Rajan: Yes.
Want macro and all.</font><br><font size=2 face="sans-serif"> Jim: Recommended
is for specialized cases, if it was for general purpose use it would be
required.</font><br><font size=2 face="sans-serif"> David: If
something would make existing implementations non-conforming, it became
"should" instead of "shall" to allow them to remain
conforming.</font><br><font size=2 face="sans-serif"> Fred: Perhaps
have a future directions section.</font><br><font size=2 face="sans-serif"> David: That
would be a background document. There may well be one there.</font><br><font size=2 face="sans-serif"> Jim: There
is also 'should' for some math functions for specialized uses. Perhaps
have this as part of a background document?</font><br><font size=2 face="sans-serif"> Fred: There was
a question asking if Jim has done any work on LaTeX for our docs?</font><br><font size=2 face="sans-serif"> Jim: No,
I haven't.</font><br><font size=2 face="sans-serif"> Jim: For the new
IEEE features, WG14 wants us to bring forward changes once IEEE is published
and we can base the changes on C2X.</font><br><font size=2 face="sans-serif"> Fred: I have a
paper on the precision selection for NaN payload free string output.</font><br><font size=2 face="sans-serif"> Rajan: CPLEX was
cancelled as a project. Just as an FYI for the reduction operations.</font><br><br><font size=2 face="sans-serif"> 754 revision:</font><br><font size=2 face="sans-serif"> They (IEEE standards
association editors) have 30 days to comment. So far nothing.</font><br><font size=2 face="sans-serif"> Looking at things
to change if we have a second ballot.</font><br><br><font size=2 face="sans-serif"> C++ Liaison:</font><br><font size=2 face="sans-serif"> Ian: Nothing new.
Harder to talk to Hubert now. Specifically the issue is what C++ does for
wide evaluation format in effect for constants (literals). Will likely
get to it this afternoon.</font><br><br><font size=2 face="sans-serif"><b> Action item details:</b></font><br><font size=2 face="sans-serif"> Min/max C specification
matches IEEE?</font><br><font size=2 face="sans-serif"> Nothing new.</font><br><font size=2 face="sans-serif"> </font><br><font size=2 face="sans-serif"> Augmented* C function
specifications match IEEE?</font><br><font size=2 face="sans-serif"> Nothing new.</font><br><font size=2 face="sans-serif"> </font><br><font size=2 face="sans-serif"> totalorder* differ for
NaN payloads: Note that we don’t have approval to move up to 754 201x
yet.</font><br><font size=2 face="sans-serif"> Revisit after we
move up to the 754 draft.</font><br><font size=2 face="sans-serif"> </font><br><font size=2 face="sans-serif"> Consider the fact that
C doesn't support the SNaN sequence that IEEE does. Can have strtod take
it as input.</font><br><font size=2 face="sans-serif"> See Jim’s 10/9
email “[Cfp-interest] AI about C support for "snan" character
sequences” and Mike’s responses</font><br><font size=2 face="sans-serif"> Jim: I thought
754 required reading of SNaN sequences, but on careful reading it was a
recommendation, not a requirement. So we are conferment with 754.</font><br><font size=2 face="sans-serif"> 754 has confirmed
this interpretation in the last 754 meeting.</font><br><br><font size=2 face="sans-serif"> Paper on macro vs function
(pointer vs arguments) causing signalling asking for recommendations from
WG14 or ask if it is a problem for anyone.</font><br><font size=2 face="sans-serif"> Jim: Currently
we have macros, functions that take pointers, etc. in the standard and
the TS's. The main issue is on x87 is that it's hard to pass arguments
without triggering Signalling NaNs. The interfaces have been there forever
though.</font><br><font size=2 face="sans-serif"> Fred: SNaN support
hasn't been required before this.</font><br><font size=2 face="sans-serif"> Jim: Do we need
to do anything? Intel/legacy platforms can keep doing what they are doing
and not be conforming.</font><br><font size=2 face="sans-serif"> Fred: WG14 can
make it a 'should' instead of a 'shall' for fabs.</font><br><font size=2 face="sans-serif"> David: Most people
using x87 probably expect it to stay as is. They know that likely no one
will do it in the x87 way in the future. Leaving it as is will be a minor
inconsistency for x87.</font><br><font size=2 face="sans-serif"> Fred: For existing
functions with problems like fabs, make it recommended practice to not
signal for SNaNs.</font><br><font size=2 face="sans-serif"> Jim: It's not a
requirement in the main body that they not signal. Just annex F.</font><br><font size=2 face="sans-serif"> Fred: Make fabs
a built-in operator is an option too.</font><br><font size=2 face="sans-serif"> Leave it as is
for now.</font><br><br><font size=2 face="sans-serif"> Fix the sqrt and rootn
identity conflicts with IEEE. </font><a href=http://wiki.edg.com/pub/CFP/WebHome/P4_CR_for_rootn.pdf><font size=2 color=blue face="sans-serif">http://wiki.edg.com/pub/CFP/WebHome/P4_CR_for_rootn.pdf</font></a><br><font size=2 face="sans-serif"> Jim: The cases
listed are intended to be 1-1 to what's in 754.</font><br><font size=2 face="sans-serif"> @Fred: Ensure that
the items for 4_CR_for_rootn.pdf match IEEE.</font><br><font size=2 face="sans-serif"> @Jim: Create a
CR for Part 4 from 4_CR_for_rootn.pdf.</font><br><br><font size=2 face="sans-serif"> Ensure pown matches IEEE
for the identity conflicts.</font><br><font size=2 face="sans-serif"> Jim: Fred (September
26th email) found one potential conflict (not a signaling nan case). 754
has it as a ballot comment to change it.</font><br><font size=2 face="sans-serif"> David: It's in
the consensus comments.</font><br><font size=2 face="sans-serif"> Jim: With the change
we are not in conflict.</font><br><br><font size=2 face="sans-serif"> C2X integration:</font><br><font size=2 face="sans-serif"> Nothing new.</font><br><br><font size=2 face="sans-serif"> Other issues:</font><br><font size=2 face="sans-serif"> Fred’s 10/23 email “Three
round nearest modes and FLT_ROUNDS” and responses</font><br><font size=2 face="sans-serif"> Jim: 754 intention
is that roundsTiesToZero is not a general rounding mode.</font><br><font size=2 face="sans-serif"> Fred: It's not
required as a general use. Should we get the spelling set?</font><br><font size=2 face="sans-serif"> Jim: No, since
no one can since it is reserved.</font><br><font size=2 face="sans-serif"> Fred: The other
issue is do we want a 1-1 mapping with FLT_ROUNDS as well?</font><br><font size=2 face="sans-serif"> Jim: FLT_ROUNDS
already has the 4 modes for binary.</font><br><font size=2 face="sans-serif"> Fred: There is
a fifth one for decimal.</font><br><font size=2 face="sans-serif"> Jim: I'd like to
see FLT_ROUNDS go away since it only pertains to addition.</font><br><font size=2 face="sans-serif"> Fred: Annex F makes
it apply to all operations.</font><br><font size=2 face="sans-serif"> Jim: Surely not.</font><br><font size=2 face="sans-serif"> Fred: F.2 says
it applies to all types. Though not operations...</font><br><font size=2 face="sans-serif"> Fred to write a
paper for this.</font><br><br><font size=2 face="sans-serif"> Fred’s 10/23 email “NAN(n-char-sequence)”
and responses</font><br><font size=2 face="sans-serif"> printf and strtod
are different in that for printf if you have ( you have to have n-char-sequence,
where strtod has to accept no n-char-sequence.</font><br><font size=2 face="sans-serif"> Jim: Not sure there
is a problem with that difference. strtod has to accept everything printf
prints, but the strings can be from things other than printf as well.</font><br><br><font size=2 face="sans-serif"> Fred’s 10/21 email “C
DR/CR 432, 467”</font><br><font size=2 face="sans-serif"> See 10/23 FP model
email from Fred for a better version.</font><br><font size=2 face="sans-serif"> Jim: For the second
change, that second clause about fk digits seems to be trying to say too
much in too little words.</font><br><font size=2 face="sans-serif"> Fred: It is eliminating
the double-double case with the spaces between zeros.</font><br><font size=2 face="sans-serif"> Fred: Open to better
words if anyone has them.</font><br><font size=2 face="sans-serif"> Jim: From the context,
it seems you have already said what a floating point number is, and all
that is left is what normalized is.</font><br><font size=2 face="sans-serif"> Fred: Not following.</font><br><font size=2 face="sans-serif"> Jim: Floating point
types are able to represent "all of the" normalized floating
point numbers. It is just writing the same as the previous statement. No
need to say anything about the fk's there.</font><br><font size=2 face="sans-serif"> Fred: For paragraph
3, the k can be larger than the actual representation. p can be larger
than what the hardware can actually do.</font><br><font size=2 face="sans-serif"> Jim: k can range
between 1 and p.</font><br><font size=2 face="sans-serif"> Fred: The p in
the model is not clearly the same as p in the hardware.</font><br><font size=2 face="sans-serif"> Jim: Saying positive
or unsigned in parenthesis, it makes it seem saying zero is enough. Perhaps
remove the parenthesis.</font><br><font size=2 face="sans-serif"> Fred: Could add
a footnote saying the rest of the standard has positive, negative and unsigned
zeros.</font><br><font size=2 face="sans-serif"> Jim: The last change
for epsilon, is this the most useful definition?</font><br><font size=2 face="sans-serif"> Fred: There is
also a math formula there.</font><br><font size=2 face="sans-serif"> Jim: Is it consistent
with double-double?</font><br><font size=2 face="sans-serif"> Fred: As far as
I know it is. Worked on the words along with the guy from IBM.</font><br><font size=2 face="sans-serif"> </font><br><font size=2 face="sans-serif"> Fred's printf/NaN/Infinity
email on 2019/10/24:</font><br><font size=2 face="sans-serif"> Prefer having the
default be matching existing code.</font><br><font size=2 face="sans-serif"> @All: Consider
the printf for NaN(n-char-sequence) bounding issue.</font><BR>