A Complex Variable Detective Story – A Disconnect Between Theory and Implementation

Rick LyonsOctober 14, 2014

Recently I was in the middle of a pencil-and-paper analysis of a digital 5-tap FIR filter having complex-valued coefficients and I encountered a surprising and thought-provoking problem. So that you can avoid the algebra difficulty I encountered, please read on.

A Surprising Algebra Puzzle

I wanted to derive the H(ω) equation for the frequency response of my FIR digital filter whose complex coefficients were h0, h1, h2, h3, and h4. I could then test the validity of my H(ω) expression by comparing its value, for a given set of filter coefficients, to the discrete Fourier transform (DFT) of the filter's time-domain impulse response. Included in my derived H(ω) equation I had a single term that took the form of y given as:

where complex coefficient h2 in polar form is h2 = Me, magnitude M is a real-valued scalar, angle θ is in the range of –π to +π radians, and the '*' symbol means conjugation.

Because there are so many occurrences of variable h2 in Eq. (1) I was fairly sure that expression could be simplified. Attempting to do so I rewrote Eq. (1) with h2 in polar form as:

Performing the division under the radical of Eq. (2), I wrote:

Neat! Equation (3)'s y = M is certainly simpler than the expressions for y in Eq. (2).

I substituted Eq. (3)'s y = M term into my filter's H(ω) frequency response equation and modeled that final equation using software. To my surprise, for one set of filter coefficients my derived H(ω) equation gave me correct results. But for another set of valid filter coefficients my H(ω) equation gave me incorrect results.

After much experimentation I learned that when I used either of Eq. (2)'s expressions for y in my H(ω) equation I obtained correct results regardless of the values of my five hk filter coefficients. So to my unpleasant surprise, I learned that in my software-modeling the expressions for y in Eq. (2) and Eq. (3) were not equal to each other!

Testing my Eq. (2) and Eq. (3) with software when I set h2 = 3 +j4, I obtained:

  y = 5 from Eq. (2), and y = 5 from Eq. (3).

That was OK so far. However when I set h2 = -3 +j4, I obtained:

  y = -5 from Eq. (2), and y = 5 from Eq. (3).

In this second case Eqs. (2) and (3) were giving me two different results. Equation (3) does not equal Eq. (2)! My algebraic steps going from Eq. (2) to Eq. (3) seemed correct to me, so what's going on here? What's the explanation for my Eq. (2) versus Eq. (3) inequality?

One Incorrect Explanation

Recalling that performing square roots on complex numbers can be tricky [1], I first thought that perhaps I should have taken the negative of the square root in Eq. (3) as:

But Eq. (4)'s y = -M is no more correct than Eq. (3)'s incorrect y = M.

Another Incorrect Explanation

Continuing to focus on the square root operation as a possible source of my Eq. (2) versus Eq. (3) inequality, I investigated how the square root of a complex number is implemented (computed) in software. The positive principal square root of a complex number a + jb is:

where the 'sgn(b)' is a plus or minus sign equal to the sign of b. A straightforward proof of Eq. (5) is given in references [2] and [3]. Interesting viewpoints regarding this 'square root of complex numbers' topic are available in reference [4].

The Square Root web page at http://en.wikipedia.org/wiki/Square_root claimed that the sgn(b) factor in Eq. (5) causes a kind of angular discontinuity associated with performing the square root of a complex number. At first I thought that claim might explain my puzzling Eq. (2) versus Eq. (3) inequality. However, my further study of this topic did not substantiate that web page's angular discontinuity claim in any way. The software implementation of Eq. (5)'s square root is not the cause of my Eq. (2) versus Eq. (3) inequality problem.

One Correct Explanation

The cause of my Eq. (2) versus Eq. (3) inequality problem lies in the permissible ranges of the angles of complex numbers represented in either rectangular or polar form. Here's the story.

In polar form a complex number's angle can be any radian value. For example, it's perfectly OK to represent a complex number x in polar form as:

The magnitude of x is two. The α angle of x is two and one eighth counterclockwise revolutions around a complex plane's origin, α = 4.25π radians or α = 765 (720+45) degrees. In polar form we can use the Laws of Exponents to square, or take the square root of, x without difficulty.

However, the α angles of complex numbers in rectangular form are restricted to be the range of:

Keeping that rectangular-form angle range restriction in mind, our above x = 2ej4.25π complex number converted to rectangular form is:

where the angle of x in Eq. (8) is α = π/4 radians (45 degrees) which is within the range of Eq. (7). The angles of all rectangular-form complex numbers are the range of –π to +π and software implementations of complex numbers are always in rectangular form! So the angle restriction of rectangular-form complex numbers is the source of my Eq. (2) versus Eq. (3) inequality problem.

To show this graphically, Figure 1 presents the anticipated angles of the polar-form complex-valued factors used in my pencil-and-paper algebra in Eqs. (2) and (3). The horizontal axes in that figure are the θ angle of the digital filter's h2 coefficient. The bold line in Figure 1(a) is, itself, h2's angle θ.

Review Figure 1 carefully. Notice how ej's 2θ angle in Figure 1(b) extends over an angular range of 4π radians. The solid line in Figure 1(d) shows the -θ angle of the (e)* = e-jθ factor in Eq. (3). The sum of that solid line and the dashed-line angle θ in Figure 1(d) produces the zero-valued angle of our final real-valued Eq. (3) y = M shown in Figure 1(e). Nothing surprising here.

Next, Figure 2 shows the angles of the Eqs. (2) and (3) factors as they are computed in software. The horizontal axes in Figure 2 are the same as those in Figure 1. As in Figure 1(a), the bold line in Figure 2(a) is the filter coefficient h2's angle θ.

Figure 2(b) shows what we've been looking for—the source of this blog's Eq. (2) versus Eq. (3) inequality. Notice in that figure how the software-computed ratio of h2/h2* = ej2θ' has the angle 2θ' that is phase wrapped and only extends over an angular range of 2π radians. The rectangular-form software-computed values for ej2θ' have angles restricted to the range -π < 2θ' ≤ +π radians.

Compare Figure 2(b)'s 2θ' angle line to Figure 1(b)'s 2θ angle line. The effects of the software-computed 2θ' angle, with its phase discontinuities, distort the remainder of the factors computed for Eq. (3) in Figure 2.

The solid line in Figure 2(d) shows the -θ' angle of the (ejθ')* = e-jθ' software-computed factor in Eq. (3). The sum of that discontinuous solid line and the dashed-line angle θ in Figure 2(d) produces the two-valued (zero radians, or –π = +π radians) angle of our final software-computed y = ±M shown in Figure 2(e).

After modeling all of this, given that h2 = Me, the correct simplification of Eq. (1) is:

where the notation 'sgn(Real(h2))' means the sign of the real part of filter coefficient h2. Or equivalently we could also write:


The conclusion here is to be cautious in your software modeling of polar-form algebraic expressions containing complex numbers whose α angles are outside the range of -π < α ≤ +π, as was my troublesome ej2θ factor in Eq. (3). When doing so, take the advice of Veronica in the 1986 movie The Fly and "Be afraid. Be very afraid."


[1] R. Lyons, " Is It True That j = $\sqrt{-1}$ ?", http://www.dsprelated.com/showarticle/475.php

[2] S. Rabinowitz, "How to Find the Square Root of a Complex Number", http://www.mathpropress.com/stan/bibliography/complexSquareRoot.pdf

[3] ikleyn, "Lesson How to take a square root of a complex number " http://www.algebra.com/algebra/homework/complex/How-to-take-a-square-root-of-a-complex-number.lesson

[4] http://math.stackexchange.com/questions/44406/how-do-i-get-the-square-root-of-a-complex-number

To post reply to a comment, click on the 'reply' button attached to each comment. To post a new comment (not a reply to a comment) check out the 'Write a Comment' tab at the top of the comments.

Please login (on the right) if you already have an account on this platform.

Otherwise, please use this form to register (free) an join one of the largest online community for Electrical/Embedded/DSP/FPGA/ML engineers: