[Cfp-interest 1336] Fw: WG14 IEEE 754-C binding meeting minutes 2019/06/19 *** Correction to next meeting date ***
Rajan Bhakta
rbhakta at us.ibm.com
Thu Jun 20 08:30:36 PDT 2019
Corrected the next meeting date.
Thanks Jim!
Regards,
Rajan Bhakta
----- Forwarded by Rajan Bhakta/Houston/IBM on 06/20/2019 10:29 AM -----
From: Rajan Bhakta/Houston/IBM
To: cfp-interest at oakapple.net
Date: 06/19/2019 11:35 AM
Subject: WG14 IEEE 754-C binding meeting minutes 2019/06/19
Attendees: Rajan, Jim, Fred (first 20 minutes), David H, Ian,
New agenda items:
None.
Carry over action items:
All: Review the rationale for part 5 a, b, c proposal. - Done.
Fred: Create papers for the SNAN initialization and unary + operation
as CFP papers (CFP 1249, 1253, 1247, 1250) for future submission to WG14.
- Remove.
Jim: Ensure that the quantum exponents table defines dN sufficiently
in C2X. - Done.
Last meeting action items:
Jim: Investigate creating our own CFP compendium. - Done.
Fred: Give a new version of the SNAN initialization paper (as per
CFP1316). - Carry over.
Jim: Point out to Jens that we're using two spellings for analog in
the current C2X draft. - Done.
Jim: Look into the commas needed in the
why_no_wide_string_strfrom_functions document, then get a document number
and submit it. - Done.
Jim: Keep rounding of negated constants on the agenda to discuss for
next meeting. - Done.
Jim: Keep fesetexcept on the agenda to discuss for next meeting when
Fred is present. - Done.
New action items:
Jim: Create a link to the 250 draft into the references section in the
C FP wiki.
Rajan: Forward the IEEE article to WG14 once David H sends it out to
us.
Jim: Draft a slide deck and a proposal based on CFP1331.
Jim: Draft a note to warn about CFP1315's rounding of negative
constants issue.
Next Meeting(s):
Wednesday, July 17th, 2019, 11:00 EST, 8:00 PST, 4PM UTC
Same teleconference number.
Please notify the group if this time slot does not work.
Discussion:
754 revision:
IEEE standards board approved the 2019 revision. Now will be edited
by the IEEE staff. Should be published this year.
*AI* Jim: Create a link to the 250 draft into the references section
in the C FP wiki.
Jim: When will IEC 60559 be updated and who initiates that?
David H: I don't know. I know it's not us or IEEE. I think they have
to do it.
No one knows of any IEC person.
Fred: David Keaton may.
Jim: Will WG14 be willing to consider including the IEEE update
rather than wait for IEC?
Rajan/Fred: They already said they are OK with taking the new IEEE
standard changes for C. No mention on waiting for IEC.
David: Article for IEEE. Maybe interesting to WG14.
*AI* Rajan: Forward the IEEE article to WG14.
C++ Liaison:
Ian: Nothing new.
C2X integration:
Part 1 – In C2X (draft
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2385.pdf)
Part 2 – In C2X.
Part 3 – A draft based on the latest C2X paper is almost ready.
Part 4a – Will be put in first before part 3 to allow part 3 to be
based on that newest working draft with part 4a already integrated in.
Part 4b - Looking as an updated TS.
Part 5a,b,c,d – Discuss later. Part 5d is a TS update.
Action item details:
Jim: Investigate creating our own CFP compendium. See Jim’s CFP 1332.
Looks like a good way forward.
Fred: Create papers for the SNAN initialization and unary + operation
as CFP papers (CFP 1249, 1253, 1247, 1250) for future submission to WG14.
See Tydeman’s CFP 1290.
Fred: Give a new version of the SNAN initialization paper (as per
CFP1316).
Leave until next time.
Jim: Ensure that the quantum exponents table defines dN sufficiently
in C2X.
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2385.pdf
Looks good.
Jim: Look into the commas needed in the
why_no_wide_string_strfrom_functions document, then get a document number
and submit it.
See http://wiki.edg.com/pub/CFP/WebHome/n2400.pdf.
Looks good.
All: Review the rationale for part 5 a, b, c proposal.
http://wiki.edg.com/pub/CFP/WebHome/cfp5x-20180624.pdf
http://wiki.edg.com/pub/CFP/WebHome/n2120.pdf
http://wiki.edg.com/pub/CFP/WebHome/n2121.pdf
http://wiki.edg.com/pub/CFP/WebHome/n2122.pdf
See Jim’s CFP 1331.
Jim: Has anything changed so we could repurpose this as a package?
Rajan/David H: I don't think anything has changed.
Jim: The listed low quality implementation is the only way to
support the existing pragmas that are there now. This also recasts it as
an annex.
Jim: Is this a basis for a slide deck?
David H: My original idea for this was to encourage performance
analysis. It was to allow the optimizer to be turned on at the hot spots.
Jim: We can add that into the reasoning. The pragmas give that
scoping.
*AI* Jim: Draft a slide deck and a proposal based on CFP1331.
Other issues
Rounding of negated floating-point constants under FENV_ROUND pragma.
See Jim’s CFP 1314 and Mike’s 5/14 reply.
Ian: Hard for us to do anything about. It is a fundamental part of
how C is designed.
David H: If you needed this to work, you could enter the number as a
hex constant, pre-rounded how you like.
Ian: A workaround is to have a different pragma around the single
constant and then go back to the normal rounding mode.
Jim: Or use the strtod function.
Ian: This is normally execution time.
Jim: We could add a warning note in the documentation (along with
workarounds possibly). Another way would be to not have the pragmas affect
constants. They would take the default rounding mode.
Ian: Does this apply to non-constants as well? Ex. -x? Only if you
want to cast to a different type so not really a problem.
*AI* Jim: Draft a note to warn about CFP1315's rounding of negative
constants issue.
fesetexcept and optional inexact
See CFP email thread (Ex. CFP1307) “fesetexcept() and optional
inexact”
David H: The point of view of the IEEE standard is the second
exception is generated by handling the first one and can be handled
differently. The flags should be viewed as being independent even though
they are correlated.
Jim: Are we agreed that fesetexcept for overflow/underflow doesn't
allow optional inexact?
Agreed.
Fred’s WG 14 papers:
See WG14 email thread “N2380: printf of NaN()”
Jim: We want to avoid having WG14 specify what goes into the
parenthesis since that goes beyond what the floating point standard
specifies. It could disallow things the floating point standard intended
to allow.
*Keep this item on the agenda for next time.
Action items from WG14 London meeting:
C FP: Give 18661 part 4a (not reduction functions) for inclusion
into C2X.
In process. Waiting for a document number.
C FP: Put N2309 into TS 18661-4 and C2X.
rootn: In the document from above.
TS DR13: Move to C2X (C FP action item).
Round result to narrower type: In the part 3 as annex draft.
TS DR16: Move to C2X (C FP action item).
cbrt macro example: Decided on the _Roundwise* were pointers to
functions that are affected by the constant rounding modes. This will go
into C2X.
TS DR20-25: Move to C2X (C FP action item).
DR22 Already in draft, others should be soon.
Tydeman, SD3 1: DR 440: Test macros for FP being 754 types [N 2323]
Result: Want something like N2323 option 1 to be put into C2X.
The macros concern the format and not anything else. Expected this
is the case.
Unnormalized
See Robert Seacord’s SC22WG14.16861, Fred’s SC22WG14.16863, and
Jim’s SC22WG14.16864.
David H: You can have unnormalized extended.
Jim: Aren't these redundant of normals/subnorms?
David H: Yes, different representations. They may have different
arithmetic properties.
David H: Part of the confusion may be terminology, if we talked
about values being normalized or not and avoided talking about
subnormalized it might have helped.
Jim: The floating point model talks about representations and
values which can be confusing.
Jim: This issue may be settled. The ball is in Robert's court.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.oakapple.net/pipermail/cfp-interest/attachments/20190620/e4f2162c/attachment-0001.html
More information about the Cfp-interest
mailing list