complex.h(3HEAD) Headers 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 │Committed │
├─────────────────────────────┼─────────────────────────────┤
│Standard │See standards(5). │
└─────────────────────────────┴─────────────────────────────┘
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.
SunOS 5.11 17 Dec 2003 complex.h(3HEAD)