[Cfp-interest] Typo correction: WG14 IEEE 754-C binding meeting minutes 2016/05/24
Rajan Bhakta
rbhakta at us.ibm.com
Tue May 24 13:02:59 PDT 2016
Hi,
Sorry, I had a typo on a name. I was in a rush to get it the mailing out
due to other meetings and have corrected it below.
Regards,
Rajan Bhakta
z/OS XL C/C++ Compiler Technical Architect
ISO C Standards Representative for Canada
C Compiler Development
Contact: rbhakta at us.ibm.com, Rajan Bhakta/Houston/IBM
----- Forwarded by Rajan Bhakta/Houston/IBM on 05/24/2016 03:01 PM -----
From: Rajan Bhakta/Houston/IBM at IBMUS
To: cfp-interest at oakapple.net
Cc: dmk at dmk.com
Date: 05/24/2016 01:16 PM
Subject: [Cfp-interest] WG14 IEEE 754-C binding meeting minutes
2016/05/24
Sent by: cfp-interest-bounces at oakapple.net
Attendees: Rajan, Jim, Fred, Marius, David Hough, Mike, David Keaton, Ian
New agenda items:
Conversion of DFP to character strings.
Last meeting action items:
Ian: Talk to Lawrence Crowl regarding proposing this IEEE-754: 2008
binding to C++ as well. - In process. - Remove from list and make it a
discussion topic.
Lawrence said C changes will get incorporated into the C++ standard
by reference.
Not applicable in this case.
Ian: Update and check the items listed and flagged under
Feature_List_Part_1. - Not done. - Remove from list.
Jim: Post updated versions (post publication) of TS parts on the wiki
with DR resolutions. - Done.
Mike: Monitor the Part 5 DTS ballot to determine whether or not to put
it in the IEEE-754 revision bibliography. - In progress.
Once it passes, this group should notify Mike to make the update to
the IEEE-754 draft permanent.
Jim: Get a backup of the CFP wiki. - Done.
On Jim's home system and home backup.
EDG creates an offsite backup every 4 hours.
Usually gives plenty of notice if they will not support a wiki in
the future.
Mike: Can we get access to the backup and test it?
*ToDo: Jim: Check with EDG for testing the offsite backup.
Fred: Contact David Keaton and Keld to see what we can do about
getting hosting for our wiki and backups for it.
WG14 wiki is still down. Unknown when it will be fixed.
David: Still have the non-wiki functional directory if needed.
Rajan: Follow up with David (cc Jim) to see how long this TS can live
and whether or not it needs to be withdrawn or made into an IS after some
period of time. - Done.
- David said no, does not need to be withdrawn and can be stabilized
(no need to vote to renew).
Jim: Invite David Keaton to help with the new C revision discussion. -
Done.
New action items:
Jim: Check with EDG for testing the offsite backup.
Next Meeting:
June 28th, 2016, 12:00 EST, 9:00 PDT
Same teleconference number.
Discussion:
David Keaton, WG14 convener, joining today.
IEEE 754 revision:
David Huff: Moving forward to completion.
A meta-question on whether to do anything with 2add or not.
Should be done before the end of the calendar year.
Arith23:
Going forward. Abstract will be able to be reviewed before
publishing.
Registration is open for anyone who wants to come.
Parts 1-5:
DR's for parts 1-3 are in process.
Drafts with changes from the DR's are on the wiki.
No DR's against part 4.
DTS for Part 5, closes in June. USA and Canada have already begun
balloting, no comments expected.
Document conversion for the C Standard: When would it be practical
for us to make the changes to it?
David K: In progress, though likely to take a while. Expecting to
publish it by end of 2017 so we should have the source much earlier than
that.
What should be proposed for the C standard (
http://wiki.edg.com/pub/CFP/WebHome/TS_18661_for_C_standard.pdf):
The new IEEE-754 revision should work with the existing TS's with
the only exception being a new function being possibly added (2add).
Part 1:
Static rounding modes support may be the most expensive part for
the implementers. Perhaps do everything other than this?
Jim: IEEE thought the dynamic modes would be prohibitively
expensive in the future architectures so they made it optional and went
with static rounding modes.
David H: More view on what programmers wanted rather than
hardware implementation. Ex. Alternate exception handling. And the
programmer generally wants only one rounding mode for a particular
computation.
For debugging, allowing dynamic changes has it's uses.
Ian: Some hardware is only capable of static, some is only
capable of dynamic. This complicates it.
Can always implement static in terms of dynamic.
Part 2:
Should list the existing DFP TR.
No major cost (implementation) deltas from the TR, and mature
enough to put into the standard as is.
Part 3:
Possible DR: _Binary16 should only be required for BFP.
David K: Short float paper presented in London.
Rajan: Does provide more than one way of doing things for some
implementations which violates one of the principles of C of only having
one way of doing things.
Jim: Similar to the standard integer types though these are
different types with the same formats.
Can use the encoding functions to go from standard to these
types and vice versa.
Part 4:
David K: The reduction functions are nice interfaces.
Rajan: Some minor overlap with CPLEX reduction functions.
Can be an annex or an optional feature.
Rajan: May be better to have these parts as separate proposals to
allow possibly more acceptable parts to pass.
David H: There are a number of new functions that have never been
implemented before and organizations may have lost the knowledge and
people to implement it.
Marius: If not required to be correctly rounded, it should not be
that bad.
Jim: There is some experience implementing these, and some
concerns about implementing them.
Part 5:
Optimization parts can be ignored since they only allow things not
require them.
Reproducibility is similar.
If the implementation already deals with types, 1 is small as
well.
Propose individual parts as separate proposals
Can do part 1 and 2 together, others as separate.
David K: More smaller proposals usually end up with better success
rates.
Show the grand strategy of part 1 then 2, then parts of 3-5
allowing easily digestible pieces.
How should we propose these?
David K: Start with the cover sheet/rationale, then the changes
to the standard.
Rajan: Perhaps have the cover sheet/rationale, list
implementers, reference the published TS, and the DR's.
Pre meeting mailing deadline is September 19th so we can have
3-4 meetings to get proposals ready.
Agree to propose parts 1 and 2 with possibly dealing with constant
rounding modes.
Focus on parts 3-5 next meeting.
Perhaps list pro's & con's for ourselves.
Conversion of DFP to character strings (Fred's 2016/05/06 email):
David H. has an action item to look into this from the IEEE 754 group.
Mike and the TR and Part 2 of the TS say that we should get an Inf and
an overflow. IEEE-754 (4.3#1, 4.3#4) says otherwise.
Jim: Don't see that in Part 2.
David H: Not the intent either.
Fred: Page 43: Example 3.
Jim: Fred is right. It uses an intermediate.
David H: Re IEEE: What format is the intermediate result? The answer
is that it is a number, not a format.
The correct answer should be 3 digit exponent with no overflow.
Fred: Our TS is wrong on this point.
Jim: Need to look at this closer.
David H: IEEE-754 had it right and we didn't translate it right in
this particular case.
Nothing specific to decimal. Should apply to binary.
Discuss this via email in the meantime until the next meeting.
Regards,
Rajan Bhakta
z/OS XL C/C++ Compiler Technical Architect
ISO C Standards Representative for Canada
C Compiler Development
Contact: rbhakta at us.ibm.com, Rajan Bhakta/Houston/IBM
_______________________________________________
Cfp-interest mailing list
Cfp-interest at oakapple.net
http://mailman.oakapple.net/mailman/listinfo/cfp-interest
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.oakapple.net/pipermail/cfp-interest/attachments/20160524/fc64c4fd/attachment.html
More information about the Cfp-interest
mailing list