Hi, so as per PR/51427, a lot of our complex functions don't correctly
handle edge cases. I've added tests for it based on annex G.
while trying to figure out issues I've noted a common fault, the use of
multiplication on complex numbers unnecessarily - I * number will be
expanded as (0+i)*number, and if number has inf it will calculate 0*inf,
which is nan. a lot of our edge cases end up being nan.
I rewrote some function (attached) to avoid this pitfall by using CMPLX
(another thing we should implement) and will happily continue with it for
others - is there interest in this?
freebsd has a somewhat insane catrig.c which seems like it handles a lot
of edge cases, but it's a little crazy. do we want it, i.e. I shouldn't
bother messing with the complex number code?
question about it:
I'm not sure whether it's necessary for a function like cacos to
manually raise inexact by itself, I feel like it should be derived from
all the functions it uses being potentially inexact. but maybe I
misunderstood how floats work.
(please respond)
#define CMPLX(x, y) __builtin_complex((double)(x), (double)(y))
#define IX(z) CMPLX(cimag(z), -creal(z))
double complex
casin(double complex z)
{
double complex zz;
double x, y;
x = creal(z);
y = cimag(z);
zz = CMPLX(x*x - y*y, 2*x*y);
return -IX (clog(IX (z) + csqrt2(1-zz)));
}
double complex
casinh(double complex z)
{
return -IX (casin2(IX (z)));
}
