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

[Jim Thomas]

> On Aug 16, 2024, at 8:43 PM, Damian McGuckin <damianm at esi.com.au> wrote:
> 
> 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.

I think we’re talking about what the general NaN propagation rule in Annex F should be. (Not sure what “normative” in this context means.) 

The current rule in F.10.1 #1 (quoted above) covers nearly all the cases in Annex F, with just a few cases being specified otherwise. 

This rule is equivalent to the NaN propagation rule in IEEE 754 for its computational and mathematical operations (6.2 and 9.2). 

The NaN propagation rule for Annex F does not apply to complex functions and Annex G. NaNs in C are defined only for real floating types. They are intentionally not defined for complex types in Annex G. So referring to a NaN complex argument or result is not meaningful.

Complex values are represented by pairs of values from the corresponding real type, so the real and imaginary components can be NaNs (and must be accounted for in the specification), but the components are not the function arguments.

There is no complex arithmetic standard corresponding to the IEEE 754 standard for real floating-point arithmetic. It might be reasonable to define NaN + i NaN to be complex NaN, but since the specification doesn't need the definition, it seems better for C not to define it. (G.3.1 does define a complex infinity, because the specification needs the definition to describe the infinity properties in G.3.2 #3.)

Let’s not change a good NaN propagation rule in Annex F to get editorial consistency with Annex G where the context is quite different. 

>> 
>>      - 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.

Is this the only technical change we’ve identified so for? 

- Jim Thomas

> 
>>      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: not available
URL: <http://mailman.oakapple.net/pipermail/cfp-interest/attachments/20240817/f8fb75ad/attachment-0001.pdf>
-------------- next part --------------