[Cfp-interest] WG14 IEEE 754-C binding meeting minutes 2014/01/07
Rajan Bhakta
rbhakta at us.ibm.com
Tue Jan 7 10:59:18 PST 2014
2014/01/07, 12:00 EST:
Attendees: Jim, Rajan, Fred, David, Ian
New agenda items:
Preliminary responses to Joseph Myers emails
Previously undone action items
Discussion of email from Paul Eggert regarding names in part 4
Old action items:
Jim: Look into using the Wiki as a backup for the documents in Word
format. - Most current version has been put up with PDF as well. Keep this
item open. - Continuing to be done
Jim: Part 4: Look for opportunities for shortening function lists by
removing suffixes. - Not done
Jim: Part 4: Send a note to the IEEE-754 group to get review of the
draft from them. - Done
Jim: Part 3: Bring up the clause letter numbering issue at the WG14
meeting and get direction on where to put it (since the C Standard editor
is normally there). - Not done
Jim: Part 3: Get a WG14 document number and post it and ask for review
from the 754 group as well. - Done
Jim: Part 4: Page 5: Fred's note first comment (2013/12/12 note) - Jim
to fix. - Done
Jim: Part 4: Page 6: Fred's note second comment (2013/12/12) - Add to
the description of atan2pi that atan2pi is atan2/pi. - Done
Jim: Part 4: Page 10: Leave issue 2 but add in other log*p* naming
suggestions made as part of the issue. - Done as issue 1
Jim: Part 4: Page 11: See if the issue 3 comment can fit in the binding
clause. - Done as clause 6
Jim: Part 4: Page 13: Add in the comment from 754 describing where this
powr function comes from. - Done
Jim: Part 4: Page 15: Lines 14, 20 boundaries should be -1 not 0. Also
the x should be lower case (including line 26). - Done
Jim: Part 4: Page 16: Make the change to the sum range to follow C
indexes. Applies to later functions using similar notation (up to page 19).
- Done
Jim: Part 4: Page 18: Line 17: sumabs -> sumprod. - Done
Fred: Part 4: Page 18: sumprod: See if the arrays have to be
non-overlapping and to see if we need to add restrict here. - Done. No
restrict needed.
Jim: Part 4: Page 21: Line 10: Change (sum) -> (each of which is a sum)
- Done
David: Part 4: Page 21: Email other suggestions to the group for action
item above. - Done
Jim: Part 4: Add in the 754 operation to C function name binding table
as in previous parts into this part. - Done as a separate table
Jim: Part 4: Get a WG14 document number and post it and ask for review
from the 754 group as well. - Done
Next Meeting:
February 13th, 2014, 12:00 EST, 9:00 PDT
Same teleconference number.
New action items:
Jim: Backup the documents in Word format. - Most current version has
been put up. Keep this item open.
Current files: http://wiki.edg.com/twiki/pub/CFP/WebHome/cfp1.docx
Current files: http://wiki.edg.com/twiki/pub/CFP/WebHome/cfp2.docx
Current files: http://wiki.edg.com/twiki/pub/CFP/WebHome/cfp3.docx
Current files: http://wiki.edg.com/twiki/pub/CFP/WebHome/cfp4.docx
Note: Should also keep versions that are equivalent to PDF's.
Jim: Part 4: Look for opportunities for shortening function lists by
removing suffixes.
Jim: Part 3: Bring up the clause letter numbering issue at the WG14
meeting and get direction on where to put it (since the C Standard editor
is normally there). Jim will email Larry about this since he will not make
the meeting.
Jim: Part 3: Page viii: Reword to make the double format types clearer.
(Joseph's 2014/01/06 email)
Jim: Part 3: Fix the typo's listed by Joseph. (Joseph's 2014/01/06
email)
Jim: Part 3: Page 3: Add in the macro as suggested. (Joseph's
2014/01/06 email)
All: Part 3: Page 9: Look at this and decide what we should do for
decimal floating types. (Joseph's 2014/01/06 email)
All: Part 3: Page 11: Look at this and decide what we should do for the
_FloatN* types and how to make it clearer what we want. (Joseph's
2014/01/06 email)
Jim: Part 3: Page 32: Item 2: Mark this as an open issue. (Joseph's
2014/01/06 email)
Jim: Part 3: Page 32: Item 3: Check and add if needed. (Joseph's
2014/01/06 email)
Jim: Part 3: Page 34-36: Check and add if needed. (Joseph's 2014/01/06
email)
Jim: Part 4: Create a spreadsheet of log and exp functions and list the
alternatives to see which conventions are being broken.
All: Part 4: Group to review the spreadsheet above and choose the best
(least worse) naming scheme.
Jim: Part 4: Attempt to make the changes as described in the "General
comment" part of the email. (Joseph's 2014/01/07 email)
Jim: Part 4: Fix the typo's listed by Joseph. (Joseph's 2014/01/07
email)
Jim: Part 4: Page 3: Item 2: Look into how to address this. (Joseph's
2014/01/07 email)
Jim: Part 4: Page 14: Add in a footnote to the end of the description
saying "cr" stands for correctly rounded. (Joseph's 2014/01/07 email)
Jim: Part 4: Page 16: Item 2: Look into rewording (ex. remove NaN
specifications) to make this clearer. (Joseph's 2014/01/07 email)
Discussion:
Part 1: Out for ISO DTS ballot. Ballot ends March 5th, 2014.
No updates.
Part 2: Out for first ISO ballot (PDTS). Ballot ends March 10th, 2014.
No updates.
Part 3: (http://wiki.edg.com/twiki/pub/CFP/WebHome/n1784.pdf)
Joseph's 2014/01/06 email:
Jim: Addressing the complicated layout can be doing the C11 + all
changes draft idea we have talked about before. It could be done as a
project for an intern.
Fred: Larry has a very modified version of the standard source. It
would be very hard for anyone else to do it.
Page viii: A rewording here should handle this.
*Jim: Part 3: Page viii: Reword to make the double format types
clearer.
*Jim: Part 3: Fix the typo's listed by Joseph.
*Jim: Part 3: Page 3: Add in the macro as suggested.
Page 9: We need to make the decision on whether to include the
extended decimal types as decimal floating types.
Decimal floating types is a defined term whereas binary floating
types is not so no parallel there.
*All: Part 3: Page 9: Look at this and decide what we should do for
decimal floating types.
Page 11: Similar to the last comment.
*All: Part 3: Page 11: Look at this and decide what we should do
for the _FloatN* types and how to make it clearer what we want.
Page 32: The macros were not intended as feature test macros even
though they could be used that way.
Rajan: Any other ones like this in the C standard? Complex is
close but not the same (since it is a group of types).
Basically, we should follow the C standard policy/format for
these.
*Jim: Part 3: Page 32: Item 2: Mark this as an open issue.
*Jim: Part 3: Page 32: Item 3: Check and add if needed.
*Jim: Part 3: Page 34-36: Check and add if needed.
Page 41: By keeping the names reserved, it helps implementations
that supports the types. It should only apply if the TS macro is specified
of course.
*Jim: Part 3: Page 41: Find a way to say the names should be
reserved (if adhering to this TS) even if the types do not exist to enhance
portability.
Part 4:
Naming of log21p: Underscore is an option.
Jim: The reduction and scaled functions with underscores are
specialized family but the general point about no underscores is still
valid.
*Jim: Part 4: Create a spreadsheet of log and exp functions and list
the alternatives to see which conventions are being broken.
*All: Part 4: Group to review the spreadsheet above and choose the
best (least worse) naming scheme.
Joseph's 2014/01/07 email (first):
Jim: There has been no attempt to go through the math functions and
go through the potential errors for the IEEE formats
Fred: I want the main body to also do what Joseph wants.
Jim: Unlikely to happen since the statement of the error conditions
is very tricky.
Jim: If you don't conform to Annex F you have a huge latitude to
what you can do and we are doing that for the new functions as well.
General comment: Agree in general.
*Jim: Part 4: Attempt to make the changes as described in the
"General comment" part of the email.
*Jim: Part 4: Fix the typo's listed by Joseph.
The error cases: The C standard doesn't normally list this
explicitly as suggested so it is not done here. Still need review the items
though.
Page 3: Jim: The functions aren't declared unless the types are. We
can make this an explicit statement.
Also the style in Part 3 and this (part 4) need to be consistent.
*Jim: Part 4: Page 3: Item 2: Look into how to address this.
Page 14: Jim: Ideally we would like to define them, and am
surprised we have not said that already somehow.
It fits what is already there in 7.31 (like cerf in 7.31.1).
*Jim: Part 4: Page 14: Add in a footnote to the end of the
description saying "cr" stands for correctly rounded.
Page 15: Symmetries need to be reviewed to ensure they are in Annex
F.
Page 16: Item 1.2: 754 says compoundn(x, 0) should return 1 for x
>= -1, for x = inf, and x = qNaN.
Jim has sent out a note asking 754 why NaN does not give NaN.
Item 2: The NaN case is not intended to raise invalid. All
numbers excludes NaN's.
*Jim: Part 4: Page 16: Item 2: Look into rewording (ex. remove NaN
specifications) to make this clearer.
We can use cr_ as correctly rounded function prefix.
Joseph's 2014/01/07 email (second): Valid comment. We need to make it
clearer.
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.oakapple.net/pipermail/cfp-interest/attachments/20140107/89c1e5ba/attachment-0001.html
More information about the Cfp-interest
mailing list