[cfp-interest 3703] Re: Comments on proposal for Annex F special cases

[Damian McGuckin]

Hi Jim,

On Thu, 6 Nov 2025, Jim Thomas wrote:

> F.10.2.4#1 and F.10.2.11#1
> -0-: Change minus symbol to hyphen. It?s part of a C expression.

Is that the negative sign in front of the atan2()?  If so, done!

> NOTE: 
> C doesn?t use a colon after ?NOTE?. 

Done.

> ?Likewise? doesn?t seem helpful.

Done.

> F.10.2.12#1 and F.10.2.13#1
>  -2-: Remove ?all?. There?s no ?all? in ?for even integers"

Done.
> 
> F.10.4.7#2 Per your suggestion in offline email discussion, change to
>    NOTE: No floating point exception is raised by frexp(x, p) for all x
> (including NaN).

I use the same syntax in atan2(), atan2pi(), frexp() and canonicalize().

I will adjust all to match the above.

> Annex F generally refers to arguments by the parameter name in the 
> prototype, which for frexp is ?value?. I don?t have a suggestion for how 
> to do that here.

OK. Now "value" makes sense.

> F.10.5.2#1 
> Fred asked about adding compound(0,n) returns 1. What other exact results,
> that 754 doesn?t mention because they are implied by correct rounding, are
> missing in Annex F? This is a separate issue, better not included in here. 

OK.

> F.10.5.4#1 
> Suggest:
> -3- hypot(+/-inf, y) returns +inf for all y (including NaN).
> -4- hypot(x, NaN) returns a NaN for -inf < x < +inf.
> It follows the thinking: hypot(+/-inf, y) returns +inf for all y (including
> NaN), but there?s the usual NaN behavior for other first arguments. The
> following would also work:
> -3- hypot(x, +/-inf) returns +inf for all x (including NaN).
> -4- hypot(NaN, y) returns a NaN for -inf < y < +inf.

Done - the latter.

> F.10.5.5#1 
> All cases: Remove ?is?after ?for?, or change ?for? to ?if?or ?when?.

Done.

> -4- Given the explicit style, maybe use ?+inf? instead of ?inf?, e.g. in 0 < y <
> +inf.

Done everywhere.

> -5- Change ?y> 0? to match -4-

No, because y can be infinity. Or am I wrong.

> -7- Why ?+1" instead of ?1?

Done.

> -17- Change ?y> 0?to match -16-.

No, because y can be infinity. Or am I wrong?

> F.10.5.6#1
> Use +/-inf to match +/-0 cases and reduce number of new cases. E.g.
> pown(+/-inf,n) returns +/-inf ? odd n > 0
> ?
> Or expand +/-0 cases to match new +/-inf ones.
> Maybe add a NOTE with the deleted statement of equivalence. Only if there
> are not a lot of similar cases.

I will get back to this one.

> F.10.7.3#1
> Maybe delete ?for any rounding direction mode?.

Done.
> 
> F.10.7.9#!
> I believe the Annex F specs for roundeven, round, trunc, ceil and floor
> should all be the same (except for the examples and references to
> examples). trunc seems to be the one out of line. Similar considerations
> might apply in 7.12.10, but I think that should be a separate
> investigation.

OK.

> F.10.7.10#1
> The ?or?makes it seem like they?re the same function. Prefer ?and? (and plural
> verbs).

Done.

> F.10.8.1#1 and F.10.8.2#1
> -1- saying "for y < 0 or y > 0?might avoid wondering about NaNs.

Done.

> F.10.9.3#1
> -1- Prefer combined exceptions (per current).
> -1- Change to ?and the result is infinite.?
> -2- Change to ?and the result is subnormal or zero.?

Done.

> F.10.9.7#1
> The rewrite loses the requirement that the functions successfully produce a
> canonical result (for valid pointers).
> -1- The quiet NaN returned must be the canonical version of the input quiet
> NaN.
> -3- ?the canonicalized version of the signaling NaN that was made quiet? sounds
> like a signaling NaN. It's intended to be the canonical version of the
> quiet NaN resulting from quieting the signaling NaN input. 
> -3- I believe the footnote was intended to apply generally, not just to
> quieting a signaling NaN. Fred?
> -4- Because the function specification covers signaling NaNs explicitly, it
> would be better to qualify all references to ?NaN?.

Somebody else might need to attack this. The current text is not in the 
format of an Annex F entry. My umpteen attempts have not gotten it right.

> General comments follow:
> 
> Unchanged cases need to be checked for the prescribed form.

I have done so but not lately.

> For Rationale for a WG14 proposal, I?d suggest casting it as improving Annex
> F by using a consistent form for special cases. Avoid subjective terms like
> ?confusing" and ?cluttered" and phrases like ?is now easier to read and
> understand?. Claim more consistent punctuation, not "punctuation corrections? -

Done.

> there might be corrections, but we haven?t (to my knowledge) consulted ISO
> guidelines regarding punctuation.

No punctuation change is not something that was not there in the current 
version. If there is a choice of two, hopefully the form I chose to keep 
is the ISO punctuation.

Will upload to Wiki later.

Thanks - Damian