man pages section 3: Library Interfaces and Headers

Exit Print View

Updated: July 2014



complex.h, complex - complex arithmetic


#include <complex.h> 


The <complex.h> header defines the following macros:


Expands to _Complex.


Expands to a constant expression of type const float _Complex, with the value of the imaginary unit (that is, a number i such that i2=−1).


Expands to _Imaginary.


Expands to a constant expression of type const float _Imaginary with the value of the imaginary unit.


Expands to either _Imaginary_I or _Complex_I. If _Imaginary_I is not defined, I expands to _Complex_I.

An application can undefine and then, if appropriate, redefine the complex, imaginary, and I macros.


Values are interpreted as radians, not degrees.


See attributes(5) for descriptions of the following attributes:

Interface Stability

See also

cabs(3M), cacos(3M), cacosh(3M), carg(3M), casin(3M), casinh(3M), catan(3M), catanh(3M), ccos(3M), ccosh(3M), cexp(3M), cimag(3M), clog(3M), conj(3M), cpow(3M), cproj(3M), creal(3M), csin(3M), csinh(3M), csqrt(3M), ctan(3M), ctanh(3M), attributes(5), standards(5)


The choice of I instead of i for the imaginary unit concedes to the widespread use of the identifier i for other purposes. The application can use a different identifier, say j, for the imaginary unit by following the inclusion of the <complex.h> header with:

#undef I
#define j _Imaginary_I

An I suffix to designate imaginary constants is not required, as multiplication by I provides a sufficiently convenient and more generally useful notation for imaginary terms. The corresponding real type for the imaginary unit is float, so that use of I for algorithmic or notational convenience does not result in widening types.

On systems with imaginary types, the application has the ability to control whether use of the macro I introduces an imaginary type, by explicitly defining I to be _Imaginary_I or _Complex_I.

Disallowing imaginary types is useful for some applications intended to run on implementations without support for such types.

The macro _Imaginary_I provides a test for whether imaginary types are supported. The cis() function (cos(x) + I*sin(x)) was considered but rejected because its implementation is easy and straightforward, even though some implementations could compute sine and cosine more efficiently in tandem.