[cfp-interest 3812] CFP paper notes and results in the WG14 March 2026 meeting

[RAJAN BHAKTA]

Note: ^ indicates further work from CFP or potential work.

Summary: Everything that we wanted in made it in. We did request to update one paper, and there were some issues that were contentious.

Details:

^C2Y proposal - Standard pragmas and headers [N3702]
  Will be updated so no votes. Just looking to make sure the direction is good.
  WG14 agrees with the direction (no objections)

C2Y proposal - Preferred quantum exponent [N3703]
  Banham: Is this adding flexibility for implementors?
  Rajan: No, it is just fixing issues in the standard and making efficient implementations of functions possible.
  Decision Poll: Do we want to adopt N3703 into C2y?
    15/0/4. In C2Y.

C2Y proposal - Clean up frexp, ldexp, and scalbn prototypes [N3704]
  Colomar: I had the alternative proposal but I like this better.
  Ballman: Any other cases like this?
  Jens: No, should have shown up in the index.
  Decision Poll: Do we want to adopt N3704 into C2y?
    18/0/1. In C2Y.

Thomas, Proposal for C2Y - Range bounds for math functions [N3731]
  ^Large discussion on the Note and how to do it (duplicate, preamble, something else) but no specific action item for CFP.
  ^Need to make sure arccos is spelled correctly.
  Jens: Agree with the paper. Another editorial suggestion. The Note should be on all places. Perhaps put it in the preamble in the math header?
  Seacord: Put it on each function.
  Banham: The issue is rounding. Also affects decimal string conversions. Should the standard introduce ulp.
  Rajan: Bigger problem, not resolving here.
  Colomar: Disagree with Robert on the length of the standard. Want a preamble.
  Myers: If we want a preamble, we should say if functions specify ranges, it applies to the values. Need to interact with clause 5. Would be a new paper with new wording. Maybe the model should mention an approximate value and rounding it, the result can be outside the mathematical value. Shouldn't have outside for things like sin/cos being outside [-1, 1].
  Rajan: We want this as it is now, and we can change the note to whatever form people want in the future.
  Bazley: Is this useful without the note?
  Rajan: Yes, clause 5's imprecision with the description change here should allow no note, but the note makes it explicit.

  Myers: We could vote this in with the comma. The arccos issue is already in the standard.
  Banham: Is this vote predicated on the Note being changed?
  Seacord: No. We should not count on future changes.

  Decision Poll: Do we want to adopt N3731 with editorial changes into C2y?
    13/0/2. Into C2Y.

Floating expressions evaluated in translation [N3732]
  Myers: Note to the editor: Remember to remove the Annex J entry when adding this paper.
  Uecker: The "shall" was a requirement for the implementation. But it could be misunderstood as for the user. This paper resolves this in a perfect way.
  Banham: This is a semantic requirement. ISO says "is" is equivalent to "shall".
  Ballman: This is clarifying this is a requirement on implementation and not on users. This is not new. This is a significant burden. With different targets it becomes harder. This paper fixes the issue, but the standard makes it hard to implement.
  Rajan: Yes, CFP was just handling the action item. Not the wider issue of implementation difficulty.

  Decision Poll: Do we want to adopt N3732 into C2y?
    14/2/1. Into C2Y.

Proposal for C2Y - Refine the language of error reporting [N3737]
^Need to make sure the dropping of the italicized term still leaves the paper good enough (for now)
  Ballman: Not any concerns with the thrust of the paper. But we use "occurs" in other places including outside of floating-point. Perhaps say an error is said to be reported or something else.
  Rajan: Would this help if it only occurs in 7.12?
  Ballman: Kind of, but not fully so it would be different from library vs language.
  Jens: I would suggest keep "occur" but make it clear that an error in a floating-point function is said to occur. Link it to floating-point.
  Bazley: Even if you define this as a term of art in that one spot in italics. I'm not sure it is sufficient.
  Rajan: If you mean drop "occurs" as being an italicized term. The rest may be enough. Good idea.
  Seacord: I don't like the italicized format idea. Don't like "is said to" phrasing. Just say "An error occurs when". A separate fix. Perhaps say "An error is said to be reported" and replace all "occurs" with the definition.
  Jens: If things are in italics, they automatically goes into the glossary. Occurs is a bad term here. Strongly would like to have a different term here.
  Ballman: Editorial question: Can we do something that says use the English definition vs our definition?
  Jens: There is a way to tag a term that will go to the index. It has to be done manually for words that are text. Happens automatically for keywords.
  Colomar: Leave it as is and make no changes.
  Ballman: Does CFP think this is so very worrying that we need to do all this new work for replacing “occurs" to fix it?
  Rajan: Work is much greater than the benefit I think.

  Opinion Poll: Do we want to adopt something along the lines of N3737 with a different term than "occur" into C2y?
    5/8/5. No direction.
  Decision Poll: Do we want to adopt N3737 as is into C2y?
    2/14/1. No direction.
  Decision Poll: Do we want to adopt N3737 without the definition and italicization of "occur" into C2y?
    8/1/7. Into C2Y.

  ^Seacord: I would like to see the "occurs" being replaced with better wording in the standard text in the floating-point sections.

Proposal for C2Y - Preferred quantum exponent for nextafterN [N3738]
  Jens: Underline the green text to help with color blindness.

  Decision Poll: Do we want to adopt N3738 as is into C2y?
    13/0/4. Into C2Y.


Regards,

Rajan Bhakta
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.oakapple.net/pipermail/cfp-interest/attachments/20260312/f9201724/attachment-0001.htm>