[Cfp-interest 3097] Re: Annex F and Annex G - primarily about special cases

[Jim Thomas]

> On Apr 10, 2024, at 10:26 PM, Damian McGuckin <damianm at esi.com.au> wrote:
> 
> 
> I am reworking these two Annexes. Most of the changes I will suggest apply to the special cases and how they are written/described with a view to
> making them more clear.
> 
> This can be regarded as a summary of emails over the last few weeks.
> 
> Special Cases are handled inconsistently both between Annex F and Annex G, and within Annex F itself (sometimes), and Annex G itself (often). That
> inconsistency makes these sections difficult reading.
> 
> I will note what I perceive as the problem, and then follow that text by a suggested solution marked '->'
> 
> In the following discussion. I will use INF to imply +INFINITY

INFINITY is a C macro. Unless specifically involving the macro, mathematical expressions are better expressed with a mathematical infinity symbol (else “infinite” or “inf" in ordinary font).  
> 
> In G.6.1, Clause 10 introduces the 'cis(y)' function, Euler's formula. Because the existing 'cexp' function from the C standard itself with a purely imaginary argument provides the same mathematics, I suggest we
> use that instead.
> 
> -> the use of 'cis(y)' will be replaced by 'cexp(iy)'.

cis() is a mathematical function. cexp() is a C library function. They are not interchangeable.
> 
> Annex F uses a mathematical relationship such as 0 < x < INF to qualify the
> domain of a function's argument for which a special case holds. On the other
> hand, Annex G uses mathematical words like positive finite 'x' for the same
> domain, wording which is less succinct and is sometimes inconsistently used
> 
> -> Mathematical relationships are now used to qualify domains for special cases
> 
> Mention of whether or not a floating-point exception is raised for a special
> case currently appears after the result but before the domain qualification
> inequality or words.  In such clauses, I would suggest that
> 
> * the domain is the most important part of the qualification but it gets
>  lost visually in the words talking about the floating-point exception,
> 
> * the domain is no longer seen in roughly the same location on a line
>  compared to other clauses where no exception is raised.
> 
> -> Any floating-point exception now appears AFTER the domain qualification.
> 
> Note that the approaches of mathematical relationships (inequalities mostly) and ensuring the domain qualification immediately follows the result make
> 
> * a domain qualification, clear, far more obvious, and more readable;
> 
> * it easier to check these domains for accuracy and consistency.
> 
> For some special cases, the domain qualification 'runs on' immediately after
> the complex 'number' which is result, i.e.
> 
> 	<function> ( <argument> ) returns <result> for +0 < y < INF
> 
> Elsewhere, a comma separates the two:
> 
> 	<function> <argument> ) returns <result> , for +0 < y < INF
> 
> The former is consistent with most of Annex F and is hence the chosen style.
> 
> -> No comma now appears before the domain qualification for a special case
> 
> Given a pair of functions 'cf()' and its inverse 'caf()', e.g. ccosh() and
> cacosh(), where both accept a complex argument and return a complex result,
> if
> 
> 	cf ( NaN + i 0 ) = NaN + i  0 .........(1)
> 
> and does not raise a floating-point exception, then, by definition, the inverse
> 
> 	caf ( NaN + i 0 ) = NaN + i 0 .........(2)

The inverse property only applies for restricted domains where both functions are one-to-one. sqr(-1) = 1 doesn’t mean sqrt(1) = -1.
> 
> and by assumption, it too does not raise a floating-point exception.
> 
> Annex G forgot this mathematical definition and returns NaN + i NaN for
> both 'cacosh' and 'catanh'.  It also chose to raise the floating-point
> exception for these cases which is inconsistent.
> 
> -> A 'NaN + i 0' argument will be correctly and consistently handled

The mathematical functions can be defined by cosh(z) = (e^z + e^(-z))/2 and acosh(z) = log(z + sqrt(z+1)*sqrt(z-1)).

cosh(x + i0) has imaginary component +0i for any number x. Thus it’s appropriate to define ccosh(NaN + i0) to be NaN + i0. On the other hand, acosh(x + iy) has a branch cut along the x axis for x < 1, and there acosh(x + 0i) does not have a +0i or any other invariant imaginary component. So cacosh(NaN + 0i) must return NaN + iNaN.

> 
> The above scenario also happens for an argument of '+0 + i NAN' passed
> to 'casinh'.  The same solution applies.
> 
> -> A '0 + i NaN' argument will be correctly and consistently handled
> 
> For functions which satisfy:
> 
> 	f(conj(z))  = conj(f(z))
> 
> Annex G says it only provides special case specifications for such functions
> in the upper half of the complex half-plane because any cases in the lower
> half of the complex half-plane are implied by that conjugate rule.  

No, it doesn’t say it only provides specification in the upper half-plane. It says "the specifications for the upper half plane imply the specifications in the lower half-plane.” With this understanding, the conjugate rule can be used selectively where it seems to result in a better (easier to understand) spec. 

- Jim Thomas

> Not all
> special cases are consistent with this approach.
> 
> -> Complex half plane special cases are now handled consistently
> 
> If anybody has any comments, suggestions or objections to those '->' approaches, please let me know.
> 
> I will post the changes subsequently after a bit more QA on the extensive list by Jerome and Jim.
> 
> Thanks - Damian
> _______________________________________________
> Cfp-interest mailing list
> Cfp-interest at oakapple.net
> http://mailman.oakapple.net/mailman/listinfo/cfp-interest

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.oakapple.net/pipermail/cfp-interest/attachments/20240411/148c1f69/attachment.htm>