# complex.h(3head) [plan9 man page]

complex.h(3HEAD) Headers complex.h(3HEAD)NAME

complex.h, complex - complex arithmeticSYNOPSIS

#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 i2-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 _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.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 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)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 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 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.1017 Dec 2003 complex.h(3HEAD)

## Check Out this Related Man Page

complex.h(3HEAD) Headers complex.h(3HEAD)NAME

complex.h, complex - complex arithmeticSYNOPSIS

#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 _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.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 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)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 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 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.1117 Dec 2003 complex.h(3HEAD)