1complex.h(3HEAD) Headers complex.h(3HEAD)
2
3
4
6 complex.h, complex - complex arithmetic
7
9 #include <complex.h>
10
11
13 The <complex.h> header defines the following macros:
14
15 complex Expands to _Complex.
16
17
18 _Complex_I Expands to a constant expression of type const float
19 _Complex, with the value of the imaginary unit (that
20 is, a number i such that i^2=−1).
21
22
23 imaginary Expands to _Imaginary.
24
25
26 _Imaginary_I Expands to a constant expression of type const float
27 _Imaginary with the value of the imaginary unit.
28
29
30 I Expands to either _Imaginary_I or _Complex_I. If _Imag‐
31 inary_I is not defined, I expands to _Complex_I.
32
33
34
35 An application can undefine and then, if appropriate, redefine the com‐
36 plex, imaginary, and I macros.
37
39 Values are interpreted as radians, not degrees.
40
42 See attributes(5) for descriptions of the following attributes:
43
44
45
46
47 ┌─────────────────────────────┬─────────────────────────────┐
48 │ ATTRIBUTE TYPE │ ATTRIBUTE VALUE │
49 ├─────────────────────────────┼─────────────────────────────┤
50 │Interface Stability │Standard │
51 └─────────────────────────────┴─────────────────────────────┘
52
54 cabs(3M), cacos(3M), cacosh(3M), carg(3M), casin(3M), casinh(3M),
55 catan(3M), catanh(3M), ccos(3M), ccosh(3M), cexp(3M), cimag(3M),
56 clog(3M), conj(3M), cpow(3M), cproj(3M), creal(3M), csin(3M),
57 csinh(3M), csqrt(3M), ctan(3M), ctanh(3M), attributes(5), standards(5)
58
60 The choice of I instead of i for the imaginary unit concedes to the
61 widespread use of the identifier i for other purposes. The application
62 can use a different identifier, say j, for the imaginary unit by fol‐
63 lowing the inclusion of the <complex.h> header with:
64
65 #undef I
66 #define j _Imaginary_I
67
68
69
70 An I suffix to designate imaginary constants is not required, as multi‐
71 plication by I provides a sufficiently convenient and more generally
72 useful notation for imaginary terms. The corresponding real type for
73 the imaginary unit is float, so that use of I for algorithmic or nota‐
74 tional convenience does not result in widening types.
75
76
77 On systems with imaginary types, the application has the ability to
78 control whether use of the macro I introduces an imaginary type, by
79 explicitly defining I to be _Imaginary_I or _Complex_I.
80
81
82 Disallowing imaginary types is useful for some applications intended to
83 run on implementations without support for such types.
84
85
86 The macro _Imaginary_I provides a test for whether imaginary types are
87 supported. The cis() function (cos(x) + I*sin(x)) was considered but
88 rejected because its implementation is easy and straightforward, even
89 though some implementations could compute sine and cosine more effi‐
90 ciently in tandem.
91
92
93
94SunOS 5.11 17 Dec 2003 complex.h(3HEAD)