[Cfp-interest 2273] C FP Summary for WG14 2021/11 meeting in progress

Thu Nov 18 06:31:48 PST 2021

Hi,

Here is a raw summary of the floating point papers that were presented
yesterday. I didn't get a chance to write down most of my responses to the
questions as I was presenting and talking at the time, but the questions
should have been mostly captured. The official WG14 minutes should capture
my responses.

Action items for CFP:
  All papers that had double-double concerns: Any new papers to handle the
double-double concerns should have a line at the top saying that the main
change was already voted into C23 and that this is a refinement to allow
other cases.
  N2806: Cleanup of 5.2.4.2.2: Split paragraph 4 into separate paragraphs
for each category of numbers if it is complicated. Leave it to the editors
(and notify them) if it is trivial.
  N2848: INFINITY macro contradiction: Look into the math.h and float.h
INFINITY macro definitions to ensure they are the same. If they are
different and not trivial to word the same, write a paper, otherwise let
the editors know so they can make any change needed.
  N2823: CFP freestanding: Want another version of this paper with more
motivation/rationale.
  N2823: CFP freestanding: Want new paper(s) for the strtod* changes for
BFP and Annex X as well. Note: It would be good to have 7.12.1#7 with
matherrhandling & matherrno has a value 0 case considered as well.

Papers:
5.9 Thomas, C23 proposal - 5.2.4.2.2 cleanup (N2672 update) [N 2806]
  Straw poll: Put N2806 into C23?
    14/0/3. Consensus.
  Straw poll: Does WG14 want to split paragraph 4 into separate categories
editorially?
    7/1/9. Consensus. ^CFP: Can do this for C23. Or editorial if simple
enough.

5.10 Thomas, C23 proposal - overflow and underflow definitions (N2746
update) [N 2805]
  Jens: Difficult to understand "ordinary accuracy"? It needs a definition,
not a footnote.
  Uecker: Similar comment to Jens, like incremental improvements. Does C
guarantee anything with rounding. Any guarantees in the FP world?
  Fred: Implementation defined for accuracy in C FP.
  Uecker: This should refer back to the clause for ordinary accuracy.
  Joseph: Ordinary accuracy may be try to cover many different things...
approx by the implementation, approx by the math result, unbounded exp for
IEEE.
  Joseph: For double double, the lower half variant has the result is the
high half with distiguous bits. This means the normalized numbers need to
be changed. For the other variant you do have lower precision, so you need
supernormal numbers and change overflow so you don't give HUGE_VAL instead
of supernormal values. There is also the POSIX one with variable precision
with the supernormal numbers.
  Jens: Seeing Josephs comment about 5.2.4.2.2p8 with the definition of
accuracy. We should be clear about what the implementation needs to
document. Need to define accuracy better.
  Ballman: There are papers for overflow for integers on Friday. I would
like to have something together for both instead of two definitions.
  Keaton: Historically the standard (outside of Annex F), never gave any
info on accuracy. It is a completely different topic than this. It is a
completely different paper.
  Joseph: Re defining accuracy. Depends a lot on the operation. Especially
library. Ex. cpow.
  Uecker: I get the point. Can we editorially change the footnote to point
to the reference that Joseph gave.

  Straw poll: Put N2805 into C23?
    10/1/5. Consensus. Goes into C23.

5.11 Thomas, C23 proposal - Annex F overflow and underflow [N 2747]
  Philipp: We just voted in the previous definition in the base C standard.
Why don't we point to that instead of what is here re tiny.

  Straw poll: Put C2747 into C23?
    12/0/5. Goes into C23.

5.12 Thomas, C23 proposal - Normal and subnormal classification [N 2842]
  Joseph: Does this fit with the current existing macros like for DFP.
  Fred: No problems with existing implementations.
  Jens: I understand this definition better than overflow/underflow. Can we
do underflow/overflow like this definition?
  Fred: Rounding changes this and that's why this is different.
  Alex: You mentioned incremental vs Big Bang. I like incremental changes
that objective improvements with no drawbacks. This massively improves
comprehensively of this.

  Straw poll: Put N2842 into C23?
    17/0/2. Goes into C23.

5.13 Thomas, C23 proposal - Clarification for max exponent macros [N 2843]
  Straw poll: Put N2843 into C23?
    16/0/2. Goes into C23.

  ^CFP: Say any refinements are refinements of paper X that was already
voted into C23 for all new papers brought forward by CFP that are
refinements like requested for double-double for this paper.

5.14 Tydeman, remquo() [N 2790]
  Straw poll: Put N2790 into C23?
    15/0/5. Goes into C23.

5.43: N2797 (Tydeman) *_HAS_SUBNORM==0 implies what?
  Joseph: These macros were added in C11. No obsolescence. We shouldn't
remove them without it. They may not cover all possible cases, but doesn't
mean they are useless. Any C++ liaison issues?
  Fred: I don't know of any C++ issues, but did remove 'gets' without any
obsolescence.
  Jens: Removing macros can invalidate code. Needs more investigation.
  Rajan: Not good to remove without a replacement.
  Alex: A user asking this implies it is in use.
  Fred: The user was an implementor who wants to know how to define them.
His answer was -1.
  Ballman: Joseph asked if this is a liaison issue. It is. C++ defines this
in the cfloat header.
  Keaton: Can someone from CFP go to the C++ liaison group.
  Fred: The absence of the macros is not painful. Easy to find out at
runtime.
  Jens: We need an action item on this. Not just liaison.

5.44: N2823 (Bhakta) CFP freestanding.
  Philipp: This is only for IEEE conformance with freestanding. No threads
means errno is global. Removing something from IEEE conformance is not
good.
  Bachmann: Having subnormals in IEEE is not optional. Having a function to
allow access is very minor so I doubt it makes sense to have it. It seems
unbalanced. N2095 says decimal floating point is not optional and small
systems would have issues with that.
  Fred: The changes to strtod is independent of freestanding and should be
done anyways. I want both alternatives.
  Banham: Is there an assumption that freestanding is not threaded. Smaller
processes uses autos'(?) but not threads as in C.
  Jens: I have difficulties with this paper. Didn't have time to prepare.
It lacks rationale and description. Need more motivation. The changes are
not worked out in the diff form. I want to see the original text as well as
the changes.
  Joseph: For alternative 1, the list of the functions excludes strfrom.
Why?
  Rajan: To avoid localization.
  Banham: Seems to go too far for alternative 1. Removing the hardware
modes is hard. It should be optional for exception handling.

  Straw poll: Does WG14 want N2823 alternative 1 in C23?
    5/3/10. No consensus.
  Straw poll: Does WG14 want N2823 alternative 2 in C23?
    4/4/10. No consensus.
  Straw poll: Does WG14 want N2823 change 7.22.1.6#7 in alternative 2 in
C23?
    9/1/9. Goes into C23.

  Joseph: The strtod is only for DFP, not BFP and Annex X. Do you want to
change those too?
  Rajan: I can write those papers if this is accepted.
  Philipp: I am uncomfortable to change them for decimal.
  Jens: Another paper will be good. I need a rationale though.
  Joseph: For the future papers for the strto functions, it would be good
to have 7.12.1#7 with matherrhandling & matherrno has a value 0.

  Straw poll: Does WG14 want something along the lines of N2823 in C23?
    9/2/7. Consensus.

  Ballman: Need the rationale and the existing wording as well as time to
prepare for this paper.
  Joseph: We could schedule more than 6 papers for a floating point day.
  Ballman: For the future, CFP is small and targeted so it may be better to
have an omnibus paper. We'd only schedule 1 paper instead of 6.
  Keaton: The committee always found it easier to approve small pieces
rather than unrelated single papers.
  Ballman: WG21 does that for issues.
  Jens: We could have an informal check of wording before things go in?

5.45: N2845
  Straw poll: Put N2845 into C23?
    17/0/1. Goes into C23.

5.46: N2846: Transformation expressions
  Jens: Non-required -> extensions or optional features
  Fred: SNaNs are part of the main text in the standard.

  Straw poll: Put N2846 into C23?
    18/0/2. Goes into C23.

5.47: N2848: Infinity macro contradiction
  Joseph: Only float.h change not math.h? Deliberate?
  Fred: Didn't we move them?
  Joseph: We copied these and math.h is obsolescent.
  Banham: Can't you just have a float constant? #.f the is Infinity.
  Jens: Like something along the lines of this. This is a normative change.
It can invalidate existing programs.
  Philipp: The suggested change is fine. Someone may want INFINITY vs
HUGE_VAL, but that is not a good case. They should have used HUGE_VAL.
Infinity as a feature test macro is useful.
  Joseph: Re: Application code would have used math.h vs float.h so it
could be good to have that difference.
  Jens: Please don't. Not a good idea to have different definitions in two
places.
  Philipp: I agree. The suggested change should be made for all INFINITY
definitions, not just one.

  Straw poll: Put the suggested change in N2848 into C23?
    19/1/0. Goes into C23.
  Straw poll: Does WG14 want both definitions of INFINITY to match the
float.h definition?
    18/0/0. Clear sentiment.

  ^CFP Look into the math.h and float.h INFINITY macro definition to ensure
they are the same.

Regards,

Rajan Bhakta
z/OS XL C/C++ Compiler Technical Architect
ISO C Standards Representative (Canada, USA), PL22.11 Chair
C/C++ Compiler Development
rbhakta at us.ibm.com

IBM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.oakapple.net/pipermail/cfp-interest/attachments/20211118/7e63bf45/attachment-0001.htm>