← board

ucomplex library (complex numbers, FPC-compatible API) — Track B

What

Port FPC rtl-extra ucomplex to lib/rtl/ucomplex.pas, API-compatible where pxx allows:

type complex = record re, im: Double; end;
const i: complex = (re: 0.0; im: 1.0);
operator + - * (complex, complex) and (complex, Double) forms;
operator = ;
function cinit(re, im: Double): complex;
{ cmod, carg, conjugate, csqrt, cexp, cln, csin, ccos, ctan }

Known pxx-vs-FPC deltas to document in the unit header:

Why (user)

Complex numbers = the one Extended-Pascal idea worth having; and this is a deliberate WORKOUT for the operator-overloading feature — early feature, nearly untested (2 thin tests: + on records, </> comparisons; *, mixed complex/Double operands, operator chains, const-param operators all uncovered). Same rationale as the vector/bignum tickets: [[feature-lib-vecmath]], [[feature-lib-bignum-operators]].

Tests (the point)

Golden test in the lib suite: arithmetic identities ((3+4i)(1−2i)+(3+4i) = 14+2i), csqrt(−1) = i, cmod(3+4i) = 5, cexp(i·π) ≈ −1, conjugate/carg; exact expected strings (FP-determinism rules — own-RTL math, watch libm divergence). Plus operator-chaining and complex-op-Double cases, which double as frontend regression coverage.

Gate

Track B: build with $(PXX_STABLE), make lib-test green. Frontend gaps found while porting → ticket the P lane, don't patch here.

Log