[Cfp-interest 3067] Re: csinh(x + i y) - G.6.3.5 - 5th bullet point of special cases

Jim Thomas jaswthomas at sbcglobal.net
Wed Apr 3 12:45:25 PDT 2024



> On Apr 2, 2024, at 5:25 PM, Damian McGuckin <damianm at esi.com.au> wrote:
> 
> 
> Jim, I am reformatting this email a bit because it is hard to see who said what.  I was chasing consistency.
> 
>> On Sat, 16 Mar 2024, Damian McGuckin wrote:
>> The special case is mentioned:
>> 
>>      csinh(x + i * INFINITY) returns NaN + i * NaN for positive
>>      finite x
>> is given.
>> Given the mathematics, I think the domain in the draft is wrong and
>> should have read 'finite non-zero x'
> 
> On Tue, 2 Apr 2024, Jim Thomas wrote:
> 
>> The domain is implicitly extended to cover finite nonzero x by the
>> requirements in the first bullet:
>> 
>>       ?csinh(conj(z)) = conj(csinh(z)) and csinh is odd.
> 
> Yes (but no from a consistency perspective)
> 
> I agree that:
> 
> The 1st item in that line says that whatever is good for +y is good for -y.

It says if csinh(x + iy) is u + iv, then csin(x - iy) is u - iv.

> 
> The 2nd item in that line says that whatever is good for +x is good for -x.

It says casinh(-z) is -csinh(z).

> 
> But exploiting that second fact is an extremely inconsistent extrapolation because no other bullet point for any special case in all Annex G exploits the odd-ness or even-ness of the function in the description of a domain as far as I can see.

Not true. Conjugate and odd and even properties are used to extend definitions particularly involving 0 and infinity components. This avoids extra bullets for cases where x or y are -0 or -inf. For example, from the second bullet

	csinh(+0 + i0) returns +0 + i0.

it follow from the first bullet (conjuge and odd) that

csinh(+0 - i0) returns +0 - i0
csinh(-0 - i0) returns -0 - i0
csinh(-0 + i0) returns -0 + i0

For the bullet in question 

	csinh(x + i inf) returns NaN + iNaN … for positive finite x

it follows from the first bullet (and the fact that -NaN and NaN refer to the same value) that

	csinh(x - i inf) returns NaN + iNaN … for positive finite x
	csinh(x - i inf) returns NaN + iNaN … for negative finite x
	csinh(x + i inf) returns NaN + iNaN … for negative finite x

Just changing “postitive finite x" to "finite non-zero x” would still need the first bullet to infer a definition for x - i inf. 

> 
> I was chasing consistency in this description.
> 
> I also said (but I hit the 'x' key twice - sorry)
> 
>>      As the special case in
>> 
>>      a) the 6th bullet point says 'finite non-zero x?,
> 
> The 6th bullet point does not exploit the odd'ness of the function when it describes the doamin, so why should the 5th bullet point.

The 6th bullet could be written to not depend on the first bullet because -NaN is NaN.

- Jim Thomas

> 
> Also, in G.6.3.6 ctanh(), the 4th and 6th bullet points do not exploit the odd'ness of the function when the domain is described either.
> 
> The description as it stands in the 5th bullet point is an outlier
> 
> For consistency with both bullet point 6 in csinh(), and again in tanh() and elsewhere such as ccosh(), we need
> 
> 	finite non-zero
> 
> in bullet point 5.
> 
> Ignore my comment about overlap. Changing to 'finite non-zero' covers it.
> 
> I also belated note that ccosh() and csinh() uses the following ordering
> for the special cases for the 3rd through 6th special cases"
> 
> 	0 + i INF
> 
> 	0 + i NAN
> 
> 	x + i INF
> 
> 	x + i NAN
> 
> and yet ctanh() shuffles these cases around and inconsistently uses
> 
> 	0 + i INF
> 
> 	x + i INF
> 
> 	0 + i NAN
> 
> 	x + i NAN
> 
> which is confusing.  It should be rearranged.
> 
> You also noted that:
> 
>> (n3219 has an erroneous periodic the middle of the first bullet. That typo has been reported to the C editor.)
> 
> Yes. Sorry. I missed that.
> 
> Thanks - Damian

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


More information about the Cfp-interest mailing list