Re: Completing libm's complex support

["Joseph S. Myers" <joseph at codesourcery dot com>]

On Thu, 22 Mar 2012, James Cloos wrote:

> There are still some functions defined in the C std which libm does't
> support.

I just checked against the functions and macros listed for complex.h in 
ISO C11 and I don't see anything missing beyond the macros "imaginary" and 
"_Imaginary_I" (which depend on compiler support for imaginary types, 
which is optional).  What do you think is missing?  (The CMPLX macros, new 
in ISO C11, require GCC 4.7 or later as they can only work properly with 
compiler support that I added for 4.7.)

Most of the function names *reserved for future use* in C11 7.31.1 aren't 
implemented, but I suspect the reason most are reserved rather than 
required in C is because of doubts that they have sufficient utility to be 
worth requiring that they be implemented.  One might thus doubt how 
valuable they would be as an addition to glibc (one could pretty reliably 
guess what the semantics would be for each of those functions if it were 
defined) - and the lack of those functions in GNU MPC (which I noted in a 
mail to the mpc-discuss list on Monday which doesn't yet seem to have been 
dealt with by the list moderators) would complicate adding testcases.

There are indeed some bugs in existing complex functions in glibc.  I 
described my understanding of the general state of libm in 
<http://sourceware.org/ml/libc-alpha/2012-02/msg00772.html> and have fixed 
various of those issues since then.  (Having reviewed every open "math" 
bug, I now don't think there are any wrong branch cut bugs left after all.  
There are however plenty of cases of intermediate overflows or inaccuracy 
through cancellation etc. that I am gradually addressing; I have a list of 
functions whose implementations I have yet to review.  Many of these are 
reasonably straightforward to address, but some are more complicated and 
will involve the use of techniques to increase precision for intermediate 
computations, such as clog near |z|=1 or cpow in cases where there is 
cancellation; I think cpow will end up the hardest function to get to 
produce both real and imaginary parts within a few ulps for all inputs.)

> Boost has well engineered code for these which trivially could be
> converted to C.
> 
> The boost license¹ looks to be a 3-clause BSD style.
> 
> Would a port of their code for the complex functions specified in C99
> be accepted into glibc?

I don't know what you think is missing, but in general new code is 
expected to be covered by an FSF copyright assignment and any exceptions 
would need to be specially approved.

-- 
Joseph S. Myers
joseph@codesourcery.com