[Cfp-interest 3215] Re: Various Updates to Annex F+G

[Damian McGuckin]

On Fri, 16 Aug 2024, Jim Thomas wrote:

> Technical
> 
> a) F.10.5
> - correct mistake - an implied -INF is NOT odd integral
> - keep old style wording for this for the moment
> 
> Where is it implied that -inf is odd integral? Please identify the 
> specific subclause(s) and bullets (F.10.5 has no content other than 
> subclauses).

Sorry. F.10.5.5. It currently says

 	for y odd integer < 0

This is an example of half English and half Mathematical. If I wanted to 
retain that style I would write as

 	for y odd finite integer < 0

to make sure somebody does not think that negatve infinity is in the 
domain.

And yes, this is editorial too.
>
>       b) G.4.3
>       - make domain of csinh(x + i INF) consistent with
>       ccosh()/ctanh()
>       - keep old style wording for this for the moment
> 
> 
> The csinh bullet for this case says ?for all positive finite x?, which covers
> all finite nonzero x because of conjugacy and oddness. This is the same
> x-domain as (explicitly stated) in the corresponding bullet for ccosh and
> ctanh. If so, this an editorial inconsistency rather than a technical one?

Correct, editorial. Silly me.

>       c) F.10.1
>       - Make a sole argument of NaN returning a NaN the normative case
> 
> 
> I can?t tell what this means. How would it be different from current F.10.1
> #14 which says "Functions with a NaN argument return a NaN result and raise
> no floating-point exception, except where explicitly stated otherwise."

I want to reword this as

 	Functions with a single argument of NaN returns a result of NaN.

I want to limit this sentence to refer only to routines like

 	f(NaN) returns NaN

(because in Annex G, it is limited to f(NaN + i NaN) returns NaN + i NaN)

That means that frexp(NaN, p) and modf(NaN, p) are not normative because
they have more than one argument.
>
>       - this is consistent with Annex G
>       - no implementation changes
>       - only affects F.10.4.7 which means that we can remove
>       parentheses
> 
> What is technically incorrect in the current specification?

Nothng. Slly me. Another editorial case. Because they are now not 
normative, I can remove the parentheses.

> Note that in G.4.2.1 in the bullet 
>
>       cacos(+/-inf + I NaN) returns NaN +/- i inf (where the sign of
>       the imaginary part of the result is unspecified).

> The parentheses need to be removed. Unlike for other cases mentioning 
> that the sign of a real or imaginary part is unspecified, here the 
> parenthesized information is not implied by the general specification in 
> G.4.1 "Unless otherwise specified, where the symbol +/- occurs in both 
> an argument and the result, the result has the same sign as the 
> argument.? The parenthesized information in the bullet above is intended 
> to be normative specification. This is a (minor but) technical issue

I have corrected this in the latest version (which I recently posted) by 
having two separate cases:

 	cacos(+inf + i NaN)
and
 	cacos(-inf + i NaN)

So the use of parentheses around normative behaviour is now correct. I 
made this change once I fully understood your explanation of normative 
text.

>       e) F.10.[4-9] - Repeat (c)
>       * use new syntax as for (c)
>       * sort out qualifying domains as for (c)
> 
> You mean (d), right?

Yes. Brain/finger linkage problem.

Thanks - Damian

Pacific Engineering Systems International ..... 20D Grose St, Glebe NSW 2037
Ph:+61-2-8571-0847 .. Fx:+61-2-9692-9623 | unsolicited email not wanted here
Views & opinions here are mine and not those of any past or present employer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: c26-afg-mods-23.pdf
Type: application/pdf
Size: 86551 bytes
Desc: 
URL: <http://mailman.oakapple.net/pipermail/cfp-interest/attachments/20240817/4529b14d/attachment-0001.pdf>