<font size=2 face="sans-serif"> <b>Attendees</b>: Rajan, Jim, Fred,
Mike, David H., David C.</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> Last meeting action items:</b></font><br><font size=2 face="sans-serif"> Rajan: Check with David
Keaton to see if SD3 will be considered in the next WG14 meeting and if
so, can the floating point proposals (other than part 1 and 2) be postponed
unless we are prepared for them. - Done.</font><br><font size=2 face="sans-serif"> Jim: List the proposals
we have in flight with WG14 and what we need to do with them (if anything).
- Done.</font><br><font size=2 face="sans-serif"> Jim: Create a new DR against
part 3 for the non-arithmetic interchange formats to create format_DECIMAL_DIG
type macros. - Done.</font><br><font size=2 face="sans-serif"> Jim: Augmented add tgmath:
Change "invokes a real function" to "invokes a function
returning a real type". - Done.</font><br><font size=2 face="sans-serif"> Jim: Augmented add: Create
a proposal for the new augmented precision functions including tgmath for
IEEE 2018 C binding. - Done.</font><br><font size=2 face="sans-serif"> Jim: Create a note to
say the existing fmin/fmax functions may not correspond to the new IEEE
754:2018 f{min/max}* functions in TS Part 1 as part of the 2018 binding
update. - Done.</font><br><br><font size=2 face="sans-serif"><b> New action items:</b></font><br><font size=2 face="sans-serif"> Jim: Activities in progress:
Obsolesce DECIMAL_DIG: No proposal needed as our last one was accepted
(N2108).</font><br><font size=2 face="sans-serif"> Jim: Activities in progress:
%a for decimal differing from binary: Change "paper" to Reflector
message 14792.</font><br><font size=2 face="sans-serif"> Jim: Activities in progress:
Change all TS Part actions to "update and re-present" instead
of just re-present.</font><br><font size=2 face="sans-serif"> Jim: Get document number
and submit DECIMAL_DIG and DIG macros for non-arithmetic formats paper
for the WG14 mailing.</font><br><font size=2 face="sans-serif"> Jim: Write a DR for the
_Roundwise in cbrt sample for the WG14 mailing.</font><br><font size=2 face="sans-serif"> David H, Mike: Make a
list of what has changed or been augmented in IEEE 754:2018.</font><br><font size=2 face="sans-serif"> Jim: Augmented arithmetic:
F.10.13 is missing the paragraph number in the second paragraph.</font><br><font size=2 face="sans-serif"> Jim: Augmented arithmetic:
F.10.13.3#4: computation t underflows -> computation of t underflows.</font><br><font size=2 face="sans-serif"> Jim: Min/Max functions:
Mention that the existing fmin/fmax functions do not distinguish bewteen
+0 and -0.</font><br><font size=2 face="sans-serif"> Jim: Draft a response
to Willem's WG14 paper (N2166) for next meeting.</font><br><font size=2 face="sans-serif"> </font><br><font size=2 face="sans-serif"><b> Next Meetings:</b></font><br><font size=2 face="sans-serif"> Tuesday October 17th,
2017, 12:00 EDT, 9:00 PST</font><br><font size=2 face="sans-serif"> Same teleconference number.</font><br><font size=2 face="sans-serif"><b> Discussion:</b></font><br><br><font size=2 face="sans-serif"> IEEE 754 revision:</font><br><font size=2 face="sans-serif"> Discussion on the
payload get and set functions. Not yet resolved.</font><br><font size=2 face="sans-serif"> Not clear the best
choice for rounding for the augmented precision functions. Most important
for higher precision. If there are other use cases, it will help knowing
them.</font><br><br><font size=2 face="sans-serif"> C++ liaison:</font><br><font size=2 face="sans-serif"> No update.</font><br><font size=2 face="sans-serif"> </font><br><font size=2 face="sans-serif"> Activities (</font><a href="http://wiki.edg.com/pub/CFP/WebHome/in_flight-20170916.pdf"><font size=2 color=blue face="sans-serif">http://wiki.edg.com/pub/CFP/WebHome/in_flight-20170916.pdf</font></a><font size=2 face="sans-serif">):</font><br><font size=2 face="sans-serif"> *Jim: Activities
in progress: Obsolesce DECIMAL_DIG: No proposal needed as our last one
was accepted (N2108)</font><br><font size=2 face="sans-serif"> *Jim: Activities
in progress: %a for decimal differing from binary: Change "paper"
to Reflector message 14792.</font><br><font size=2 face="sans-serif"> IEEE-754:2018 update:
Can start on draft of a paper, but don't send it in until it passes ballot.</font><br><font size=2 face="sans-serif"> *Jim: Activities
in progress: Change all part actions to update and represent instead of
just represent.</font><br><font size=2 face="sans-serif"> </font><br><font size=2 face="sans-serif"> For next WG14 meeting:</font><br><font size=2 face="sans-serif"> Obsolesce DECIMAL_DIG:</font><br><font size=2 face="sans-serif"> Discussed
already.</font><br><font size=2 face="sans-serif"> </font><br><font size=2 face="sans-serif"> DECIMAL_DIG and
DIG macros for non-arithmetic formats:</font><br><font size=2 face="sans-serif"> Waiting
for the document #. Should be in the mailing.</font><br><font size=2 face="sans-serif"> *Jim: Get
document number and submit DECIMAL_DIG and DIG macros for non-arithmetic
formats paper for the WG14 mailing.</font><br><font size=2 face="sans-serif"> </font><br><font size=2 face="sans-serif"> %a formatting consistency:</font><br><font size=2 face="sans-serif"> Discussed.</font><br><font size=2 face="sans-serif"> </font><br><font size=2 face="sans-serif"> _Roundwise in cbrt
sample (Joseph Myers):</font><br><font size=2 face="sans-serif"> *Jim: Write
a DR for the _Roundwise in cbrt sample for the WG14 mailing.</font><br><font size=2 face="sans-serif"> </font><br><font size=2 face="sans-serif"> Binding for IEEE 754-2018:</font><br><font size=2 face="sans-serif"> WG14 paper about
updating to IEEE 754-2018:</font><br><font size=2 face="sans-serif"> *David H:
Can make a list of what has changed or been augmented with Mike. Will need
a WG14 person to translate it into WG14 wording.</font><br><font size=2 face="sans-serif"> </font><br><font size=2 face="sans-serif"> Functions for augmented
arithmetic (</font><a href="http://wiki.edg.com/pub/CFP/WebHome/augop_spec-20170915.pdf"><font size=2 color=blue face="sans-serif">http://wiki.edg.com/pub/CFP/WebHome/augop_spec-20170915.pdf</font></a><font size=2 face="sans-serif">):</font><br><font size=2 face="sans-serif"> Part 4 update.</font><br><font size=2 face="sans-serif"> *Jim: Augmented
arithmetic: F.10.13 is missing the paragraph number in the second paragraph.</font><br><font size=2 face="sans-serif"> *Jim: Augmented
arithmetic: F.10.13.3#4: computation t underflows -> computation of
t underflows</font><br><font size=2 face="sans-serif"> Should we
reconsider this being IEEE only?</font><br><font size=2 face="sans-serif"> Any
other implementations have non-IEEE and are up to date with the standards?</font><br><font size=2 face="sans-serif"> Can
do general wording with no specific rounding in the main body of the standard
and then specify the rounding method in Annex F.</font><br><font size=2 face="sans-serif"> Will wait
for 754 to decide what they will do with these functions.</font><br><font size=2 face="sans-serif"> </font><br><font size=2 face="sans-serif"> Min/max functions
(</font><a href="http://wiki.edg.com/pub/CFP/WebHome/min-max_spec-20170924.pdf"><font size=2 color=blue face="sans-serif">http://wiki.edg.com/pub/CFP/WebHome/min-max_spec-20170924.pdf</font></a><font size=2 face="sans-serif">):</font><br><font size=2 face="sans-serif"> *Existing
fmin/fmax don't distinguish between +0 and -0.</font><br><font size=2 face="sans-serif"> </font><br><font size=2 face="sans-serif"> Payload functions:</font><br><font size=2 face="sans-serif"> If IEEE
removes these functions, should they be removed from Part 1?</font><br><font size=2 face="sans-serif"> Mike: Decimal
has the payload well defined. N-1 digits. How the payload is used is undefined.</font><br><font size=2 face="sans-serif"> Jim: Implementations
can use some of the bits in the payload for themselves while some bits
can be for the user. The definition of the payload is for diagnostic information
in the glossary in the 754 spec.</font><br><font size=2 face="sans-serif"> Not clear
if the user has access to everything in the payload due to the wording
implying diagnostic information in there as well.</font><br><font size=2 face="sans-serif"> Don't want
to conflict with any hardware or software payload values if the user wants
to set their own.</font><br><font size=2 face="sans-serif"> Will wait
to see what 754 does.</font><br><font size=2 face="sans-serif"> </font><br><font size=2 face="sans-serif"> Other:</font><br><font size=2 face="sans-serif"> Willem Wakker evaluation
formats (N2166):</font><br><font size=2 face="sans-serif"> Problem
1) Agree that evaluation format should be defined.</font><br><font size=2 face="sans-serif"> Not
sure about where the text goes (language vs environment).</font><br><font size=2 face="sans-serif"> Seems
to fit better where it is as part of the floating point model.</font><br><font size=2 face="sans-serif"> Problem
2) The change in DR500 seems to be fine and it is not unclear.</font><br><font size=2 face="sans-serif"> Characterization
vs defined: Due to the use of characterization when discussing a number
of things relating to this in the standard (like number of digits).</font><br><font size=2 face="sans-serif"> Problem
3) Can see the potential problem, but not sure if it is characterized correctly
with the assumptions given. Ex. sloppy programmers.</font><br><font size=2 face="sans-serif"> Note,
sloppy programmers are the vast majority of programmers.</font><br><font size=2 face="sans-serif"> Problem
4) Having stricter behaviour in Annex F allows more portability and hence
it does deal with IEEE.</font><br><font size=2 face="sans-serif"> There
was discussion in WG14 for this and it was decided to allow wide, but was
OK with restricting it in Annex F.</font><br><font size=2 face="sans-serif"> Don't
want to change Annex F.</font><br><font size=2 face="sans-serif"> </font><br><font size=2 face="sans-serif"> Fred: Some
implementations do have wider return values for some types and not for
all.</font><br><font size=2 face="sans-serif"> Jim: Don't
think we ever intended for FLT_EVAL_METHOD to affect function returns.</font><br><font size=2 face="sans-serif"> Fred will
follow up with clarifying this return value issue.</font><br><font size=2 face="sans-serif"> </font><br><font size=2 face="sans-serif"> Jim: Need
more words to get implicit conversions included with what is in 5.2.4.2.2#9
after DR500.</font><br><font size=2 face="sans-serif"> </font><br><font size=2 face="sans-serif"> TC's:</font><br><font size=2 face="sans-serif"> 6)
Looks good in principle, but should not require a cast (cast is a runtime
operation) so you need to use a static constant or hex floating point.</font><br><font size=2 face="sans-serif"> </font><br><font size=2 face="sans-serif"> *Jim: Draft
a response to Willem's WG14 paper (N2166) for next meeting.</font><br><br><font size=2 face="sans-serif"> </font><BR>