[Cfp-interest 1385] Re: WG14 IEEE 754-C binding meeting minutes 2019/08/21
Ian McIntosh
ianmc at eol.ca
Wed Aug 21 12:09:13 PDT 2019
BODY { font-family:Arial, Helvetica, sans-serif;font-size:12px; }I
have theatre tickets that day and need to be downtown (which takes
almost an hour by bus and subway) by halfway through the call. You
probably should just do without me.
I apologize for missing today. I lost my ToDo list a few months ago
when my had drive failed, and haven't reconstructed it yet. I planned
to do what worked the last few months - check the email from a month
ago - but that was very slow because of networking notworking, and
the last few minutes don't contain the information. After nearly an
hour I gave up.
- Ian
On Wed 19/08/21 2:22 PM , "Rajan Bhakta" rbhakta at us.ibm.com sent:
Attendees: Rajan, Jim, David H., Fred, Mike New agenda items:
None. Carry over action items:
Rajan: Forward the IEEE article to WG14 once David H sends it
out to us. - Done (sent on July 17th)
Jim: Draft a slide deck and a proposal based on CFP1331. - Keep
open.
Last meeting action items:
Jim: Add wording to the CFP1331 proposal make it clear this is
for particular evaluation methods, and submit the document to W14. -
Done.
Jim: Add a statement as to why there is a second name for log1p
as a footnote as a new proposal. - Done.
Fred: Submit CFP 1340 to WG14. - Done.
Jim: Reword CFP 1337 as per action item discussion in the
2019/07/17 meeting. - Done.
Jim: Send CFP 1349 to the WG14 reflector as the CFP position. -
Done.
Fred: Write a paper to make the range error for small nonzero x
consistent for expm1, logp1, log10p1's other base functions. - Done.
Jim: Add in the normalized discussion from Fred (CFP 1341, CFP
1342) to the agenda for next meeting. - Done.
New action items:
Jim: Reword CFP1337 to avoid stating standard types with
non-power-of-2 bases with hexadecimal still being exact. Submit as an
N document.
Jim: Respond with needing both NAN and NAN( forms, and what the
payload flexibility should be.
Fred: Rewrite the proposed CFP1360 paper using the CFP
recommendations.
Jim: Discuss the namespace issue next meeting.
Jim: For the FLT_EVAL_METHOD example, add _Float16 in since it
can show that evaluation to type is not always true.
Next Meeting(s):
Wednesday, September 18th, 2019, 11:00 EST, 8:00 PST, 4PM UTC
Same teleconference number.
Please notify the group if this time slot does not work.
David H may be on call for Jury duty.
Fred can't make it (in Africa!) Discussion:
754 revision:
No public comment yet requiring a response.
New editor for the next revision but no chair. New starter kit
for editor will be sent out to people like Jim.
For IEC, they need to make the first move. David H. will check
with the IEEE contact on how that starts. C++ Liaison:
Nothing.
C2X integration:
Draft with TS 1, 2, and 4a
Part 3
The above parts will likely come out as an N doc soon from
Jens.
Part 4b - Looking as an updated TS.
Part 5a,b,c,d Action item details:
Jim: Draft a slide deck based on CFP1331
(http://wiki.edg.com/pub/CFP/WebHome/C2x_proposal_-_TS_18661-5abc-20190709.pdf)
[1]
Not done. Jim: Add wording to the CFP1331 proposal make
it clear this is for particular evaluation methods, and submit the
document to W14 (http://wiki.edg.com/pub/CFP/WebHome/n2407.pdf) [2]
Looks good. Jim: Add a statement as to why there is a
second name for log1p as a footnote as a new proposal
(http://wiki.edg.com/pub/CFP/WebHome/C2x_proposal_-_why_logp1-20190719.pdf)
[3]
Looks good. Fred: Submit CFP 1340 to WG14
(http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2406.htm) [4]
Looks good. Jim: Reword CFP 1337 as per action item
discussion in the 2019/07/17 meeting (See CFP 1371)
Fred: Since standard floating types could be base 10 for
example, hexadecimal floating constants would still round.
*AI*: Jim to reword CFP1337 to avoid stating standard types
with non-power-of-2 bases with hexadecimal still being exact. Submit
as an N document. Jim: Send CFP 1349 to the WG14 reflector as
the CFP position. See SC22WG14.16914 and SC22WG14.16919 (See also CFP
1373, 1374)
Rajan: z/OS XL C and C++ both use the NAN( form so it cannot
be obsolesced.
*AI*: Jim: Respond with needing both NAN and NAN( forms, and
what the payload flexibility should be. Fred: Write a paper to
make the range error for small nonzero x consistent for expm1, logp1,
log10p1's other base functions (See CFP 1357, 1360)
Jim: As a CFP recommendation, we could say add finite.
For the second issue of negative numbers, we could say things
like abs(x) or say magnitude. We should avoid ambiguity.
Fred: Both large and small are ambiguous.
Jim: Whenever we mean magnitude, we say magnitude.
Mike: Are you saying when it cannot be encoded?
Fred: No, this is an argument, a domain, which is encoded.
David: "magnitude of positive finite x is too large" should be
used if that's what we mean. May be a large change.
This is the CFP recommendation as well ("magnitude of positive
finite x").
*AI*: Fred: Rewrite the proposed CFP1360 paper using the CFP
recommendations.
Jim: Add in the normalized discussion from Fred (CFP 1341, CFP
1342) to the agenda for next meeting.
What does “normalized” mean in C? (See CFP 1380)
David: Instead of 'contained', should you use 'represent'?
Jim: 'Contains' is what is there now.
Fred: Specifically getting rid of unnormalized.
Jim: Yes, that is a representation.
Fred: That gets rid of a lot of DFP numbers (f1 = 0 but not
sub-norms)
Jim: No, but they can all be normalized.
Fred: Epsilons go back to being ambiguous. Ex. double-double.
Jim: No, that is outside the model, but allowed.
Fred: That is not what you said in the
classification/characterization macros.
Jim: Let me think about that. NORM_MAX would be the maximum
model value.
Other issues:
Parameter tables for TS 3 formats
http://wiki.edg.com/pub/CFP/WebHome/parameter_tables_for_Annex_N-20190820.pdf
[5]
Looks good. Example for FLT_EVAL_METHOD
http://wiki.edg.com/pub/CFP/WebHome/Example_for_FLT_EVAL_METHOD-20190815.pdf
[6]
Rajan: Not worth change in practice.
Is there a case where the blanket prohibition of mixing
standard types and interchange types where this matters?
*AI*: Jim: For the FLT_EVAL_METHOD example, add _Float16 in
since it can show that evaluation to type is not always true.
Namespace intrusion
Jens has sent a paper about the introduction of new names due
to the integration of the TS's into the standard.
He says user's can't avoid them since no prefix. Proposing
having reserved prefixes. Ex. Functions returning floats would have
an flt_ prefix like flt_sinpi, and FLT_ for macros.
Proposal is to only do this for the new additions (not
changing existing C18 functions).
Points out a real problem.
Since we modeled our names on what is already there in C this
caused this issue.
Jens position is we should address the issue, not WG14 in
general.
Rajan: We can see if WG14 wants to do this. I.e. If (A) WG14
wants to do something about the names added in and (B) directs CFP to
do it, we can work on it. Otherwise we shouldn't do it.
Fred/David: Agree.
Fred: The WANT macro's could solve this issue.
Jim: No, still an issue due to the library side.
Fred: They are weak externals. If the user defines it, it
wins, otherwise the math library does.
Rajan: Joseph hasn't said anything about this being a
problem for his users and us unilaterally changing it may harm GCC's
users.
Jim: Some things seemed good like prefixing SNAN. Also suffix
vs prefix.
*AI*: Discuss the namespace issue next meeting.
Specifying more special cases for math functions, e.g., periodicity
for half-revolution trig functions. Perhaps as recommended practice.
SNANF (See CFP 1366, 1372):
Fred: FLT_EVAL_METHOD 1 or 2 can give surprising results
Jim: It is only for certain operations. It should not affect
this.
Other:
Activities:
Review activities in progress
Links:
------
[1]
http://wiki.edg.com/pub/CFP/WebHome/C2x_proposal_-_TS_18661-5abc-20190709.pdf)
[2] http://wiki.edg.com/pub/CFP/WebHome/n2407.pdf)
[3]
http://wiki.edg.com/pub/CFP/WebHome/C2x_proposal_-_why_logp1-20190719.pdf)
[4] http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2406.htm)
[5]
http://wiki.edg.com/pub/CFP/WebHome/parameter_tables_for_Annex_N-20190820.pdf
[6]
http://wiki.edg.com/pub/CFP/WebHome/Example_for_FLT_EVAL_METHOD-20190815.pdf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.oakapple.net/pipermail/cfp-interest/attachments/20190821/a0141ad8/attachment.html
More information about the Cfp-interest
mailing list