[Cfp-interest 3071] Re: casinh(x + iNaN) - Annex G.6.3.2

[Jim Thomas]

> On Apr 3, 2024, at 10:34 PM, Damian McGuckin <damianm at esi.com.au> wrote:
> 
> On Wed, 3 Apr 2024, Jim Thomas wrote:
> 
>>> For a purely imaginary argument, which is where all this is coming from,
>> 
>>> G.7 says
>>> 
>>> 	casinh(i NaN) = i asin(NaN) = i NaN
>>> 
>>> So, Eq(1) above is now
>>> 
>>> 	casinh(0 + i NaN) = 0 + i NaN        .... (2)
>> 
>> Assuming 0 is +0, (2) would imply that the real part of casinh(+0 + iy) is +0 for any (finite or infinite) number y, contrary to bullet 3.
> 
> Yes. Something is weird.
> 
> The G.7 formula
> 
> 	casinh(0 + i y) = i asin(y)

It’s

	casinh(iy) = i asin(y)

> 
> is only valid for |y| <= 1. After that, the G.7 formula will return a NaN because no asin() function will ever accept a value outside that range. On the other hand, a complex function can expand into complex space.

The formula is defining a function on imaginary numbers, not complex ones.

> 
> Purely Imaginary numbers introduce their own set of issues.
> 
> Are we sure that
> 
> 	asinh(iy) = i asin(y)
> 
> is a valid inclusion in the current table in clause 2 of G.7.

There might be a more general issue with whether the type-generic macros should ever introduce functions on imaginary types, because of portability problems between implementations that have imaginary types and those that don’t. Maybe this issue can be viewed as part of the bigger one of what to do with imaginary types.

- Jim Thomas

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