COMPLEX.H(3HEAD)COMPLEX.H(3HEAD)NAME
complex.h, complex - complex arithmetic
SYNOPSIS
#include <complex.h>
DESCRIPTION
The <complex.h> header defines the following macros:
complex
Expands to _Complex.
_Complex_I
Expands to a constant expression of type const float
_Complex, with the value of the imaginary unit (that
is, a number i such that i^2=−1).
imaginary
Expands to _Imaginary.
_Imaginary_I
Expands to a constant expression of type const float
_Imaginary with the value of the imaginary unit.
I
Expands to either _Imaginary_I or _Complex_I. If _Imag‐
inary_I is not defined, I expands to _Complex_I.
An application can undefine and then, if appropriate, redefine the com‐
plex, imaginary, and I macros.
USAGE
Values are interpreted as radians, not degrees.
ATTRIBUTES
See attributes(5) for descriptions of the following attributes:
┌────────────────────┬─────────────────┐
│ ATTRIBUTE TYPE │ ATTRIBUTE VALUE │
├────────────────────┼─────────────────┤
│Interface Stability │ Standard │
└────────────────────┴─────────────────┘
SEE ALSOcabs(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)NOTES
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 fol‐
lowing 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 multi‐
plication 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 nota‐
tional 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 effi‐
ciently in tandem.
Dec 17, 2003 COMPLEX.H(3HEAD)