DSPRelated.com
Forums

Complex versus real numbers

Started by Chris Bore August 25, 2009
On Aug 26, 5:29&#4294967295;am, "Phil O. Sopher" <inva...@invalid.invalid> wrote:
> "Jerry Avins" <j...@ieee.org> wrote in message > > news:S4Ukm.284435$Ta5.144832@newsfe15.iad... > > > > > ..... To calculate sqrt(a^2+b^2) on a slide rule, experienced users > > calculate a/sin(atan(a/b)). > > Wow! > > No matter how much maths ("math" to the Yanks) you have under > your belt, there's always yet another fascinating insight lurking just > around the corner!
Jerry is full of fascinating insights. I actually used a slide rule in high school (and got a circular one so i wouldn't have to move it from one end to the other), but when i migrated to college, the TI SR-50 calculator (that had transcendentals) came out at $150 and the slide rule was no more. but i never knew of that identity. still seems like it would be a mess to do without writing *something* down on paper, but i can conceive of a slide rule jock one generation older than me doing it without paper. r b-j
On 26 Aug, 23:07, robert bristow-johnson <r...@audioimagination.com>
wrote:
> &#4294967295;I actually used a slide rule > in high school (and got a circular one so i wouldn't have to move it > from one end to the other),
You didn't, by any chance, use that slide rule when you first encountered the DFT...? ;) Rune
On Aug 25, 8:28&#4294967295;am, Chris Bore <chris.b...@gmail.com> wrote:
> I repeatedly come across objections to using complex numbers for DSP. > I wonder if there is a good way that I can explain without struggling? > > The current case concerns ultrasound, where the measurement is of > pressure (on a transducer). My processing uses complex numbers, which > naturally arise when I demodulate the signal. The question I am asked > is, why are complex numbers necessary when the signal itself seems to > be real-valued? > > My answer (one of them) is that the signal is modelled using complex > exponentials (Fourier analysis) and so this is the natural way to > handle those quantities. But often, a measurement of > 'amplitude' (instantaneous, real-valued, pressure) is desired, and > this seems to be a real-valued quantity. My argument here is that this > is modelled as the sum of two complex exponentials, contra-rotating > (one with +ve and one with -ve frequency), to produce a resultant that > happens to have zero imaginary part. > > So far so clear. But we can also derive Foruier transforms that are > based on sums of sine and cosine functions - each of which seem to be > real-valued quantities, and so this bypasses the complex > implementation. My argument here is that this is the same as complex > numbers, only in a different form where the complex arithmetic is done > explicitly by the way the sine and cosine terms are added and > multiplied, and where amplitude/phase replace real/imaginary in a > different arithmetic. But my current disputee convincingly suggests > that the complex representation is therefore unnecessary. > > Two questions: > > 1) am I correct in saying that the sine+cosine transform simply > duplicates complex arithmetic by inventing a sort of phase/amplitude > arithmetic? > > 2) is there a simple and convincing argument to explain this if it is > the case? > > One further issue. If I am interested in 'amplitude', then for example > if I average two numbers of equal amplitude and opposite phase, then > if I use a complex representation the 'average' amplitude is zero, > whereas if I average only their amplitudes then the average is equal > to either of the original amplitudes. Clearly the second case is not > the same measure as the first, but is there an easy explanation as to > why and what it measures? > > Thanks, > > Chris > ===================== > Chris Bore > BORES Signal Processingwww.bores.com
I would show them this video and explain to them that if they cannot get this, then complex numbers are beyond their grasp. http://www.youtube.com/watch?v=fnupL42gmF4 the only way to get repetitive motion explained mathematically is by using complex numbers.
Rune Allnor wrote:
> On 26 Aug, 23:07, robert bristow-johnson <r...@audioimagination.com> > wrote: >> I actually used a slide rule >> in high school (and got a circular one so i wouldn't have to move it >> from one end to the other), > > You didn't, by any chance, use that slide rule when you > first encountered the DFT...? ;)
I did. I called it a Fourier series then, and used it to compute the expected distortion of open-loop Class-B audio amplifiers used as plate modulators in radio transmitters. What goes around comes around. Jerry -- Engineering is the art of making what you want from things you can get. &#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;
Chris Bore  <chris.bore@gmail.com> wrote:

>I repeatedly come across objections to using complex numbers for DSP. >I wonder if there is a good way that I can explain without struggling? > >The current case concerns ultrasound, where the measurement is of >pressure (on a transducer). My processing uses complex numbers, which >naturally arise when I demodulate the signal. The question I am asked >is, why are complex numbers necessary when the signal itself seems to >be real-valued? > >My answer (one of them) is that the signal is modelled using complex >exponentials (Fourier analysis) and so this is the natural way to >handle those quantities. But often, a measurement of >'amplitude' (instantaneous, real-valued, pressure) is desired, and >this seems to be a real-valued quantity. My argument here is that this >is modelled as the sum of two complex exponentials, contra-rotating >(one with +ve and one with -ve frequency), to produce a resultant that >happens to have zero imaginary part. > >So far so clear. But we can also derive Foruier transforms that are >based on sums of sine and cosine functions - each of which seem to be >real-valued quantities, and so this bypasses the complex >implementation. My argument here is that this is the same as complex >numbers, only in a different form where the complex arithmetic is done >explicitly by the way the sine and cosine terms are added and >multiplied, and where amplitude/phase replace real/imaginary in a >different arithmetic. But my current disputee convincingly suggests >that the complex representation is therefore unnecessary.
There are scenarios where one might need to conform to a practice of not using complex numbers. For example, if the DSP designer is creating design input for a hardware group, and the local practice is that variables be scalars and not complex, so that variable names in the design input can exactly match variable names in hardware, that's probably a good enough reason to not use complex numbers -- in the relevant documents. Not that this is the only possible or most reasonable convention; but it's not worth trying to dispute it if there's enough local history of doing it that way. To claim that DSP designers should not use complex numbers in their algorithms is of course silly, but requiring that they be separated into their real and imaginary parts at some point in the design flow is not unreasonable. Steve
Phil O. Sopher wrote:
> "Jerry Avins" <jya@ieee.org> wrote in message > news:S4Ukm.284435$Ta5.144832@newsfe15.iad... >> ..... To calculate sqrt(a^2+b^2) on a slide rule, experienced users >> calculate a/sin(atan(a/b)). > > Wow! > > No matter how much maths ("math" to the Yanks) you have under > your belt, there's always yet another fascinating insight lurking just > around the corner!
It's just a mechanical operation, like turning the crank on a Curta (http://www.youtube.com/watch?v=HYsOi6L_Pw4). I had to go through the motions a few times to understand exactly what I was doing. Jerry -- Engineering is the art of making what you want from things you can get. &#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;
brent wrote:

   ...

> the only way to get repetitive motion explained mathematically is by > using complex numbers.
Oh come now! Consider the elliptic repetitive motion defined by the parametric equations For 0<t<infinity; y = sin(at) and x = ((1 + sqrt(5))/2) * cos(t) (I think the golden mean is pretty.) Jerry -- Engineering is the art of making what you want from things you can get. &#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;
On Aug 26, 11:15&#4294967295;pm, Jerry Avins <j...@ieee.org> wrote:
> brent wrote: > > &#4294967295; &#4294967295;... > > > the only way to get repetitive motion explained mathematically is by > > using complex numbers. > > Oh come now! Consider the elliptic repetitive motion defined by the > parametric equations > > &#4294967295; For 0<t<infinity; y = sin(at) and > &#4294967295; x = ((1 + sqrt(5))/2) * cos(t) (I think the golden mean is pretty.) > > Jerry > -- > Engineering is the art of making what you want from things you can get. > &#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;
Well, you are employing circular reasoning ( ha). By employing cosines and sines you have employed complex numbers. a complex exponential is like an atom and a sinusoid is like a molecule. It takes two atoms (complex exponentials) to make a molecule (sinusoid). It is better to work with and understand the atoms (complex exponentials) than to only work with molecules (sinusoids). So If I say you cannot make steam without hydrogen and oxygen you don't get credit by saying that you can do it with water :-).
Jerry Avins <jya@ieee.org> wrote:
< brent wrote:
 
<   ...
 
<> the only way to get repetitive motion explained 
<> mathematically is by using complex numbers.
 
< Oh come now! Consider the elliptic repetitive motion defined by the 
< parametric equations

It does seem like a little bit of an exaggeration.  Though
some might consider sine and cosine forms of exponentials.
 
<  For 0<t<infinity; y = sin(at) and
<  x = ((1 + sqrt(5))/2) * cos(t) (I think the golden mean is pretty.)

On the other hand, working with eliptical polarized light in
other than complex math won't be so easy.

Also, previously I said that in physics amplitude includes phase.
That might not be necessary.  What is needed is that you know
the relative phase when adding.  In optics, there is usually no
absolute phase, so relative phase is all you have, and all you need.
Even more in quantum mechanics.  

When you say "add the amplitude", then you have to include the
appropriate phase term, not just add the numbers.

Anyway, the simple cases aren't so hard to do with sine and cosine,
but it gets hard fast.

-- glen

On Aug 26, 10:58=A0pm, spop...@speedymail.org (Steve Pope) wrote:
> > To claim that DSP designers should not use complex numbers > in their algorithms is of course silly, but requiring that > they be separated into their real and imaginary parts > at some point in the design flow is not unreasonable.
ultimately, that's what we do. every piece of real equipment (like CPUs and DSPs and FPGAs) does arithmetic in reality on real numbers. ultimately our compact and concise equations involving complex quantities *is* separated into two sets, one equating the real parts on both sides of the =3D sign and the other equating the imaginary parts. i have still yet to apply a voltmeter to a voltage and measure 3 + j*4 volts. scaling by a constant, the derivative (w.r.t. time), and the delay operation (w.r.t. time) applied to either sinusoids or exponentials will result in other sinusoids or exponentials respectively (with the same omega or alpha, respectively). but we know it's more squirrelly with sinusoids. exponentials make for very clean eigenfunctions with operations such as scaling, differentiation, and shifting (delay). fortunately Euler saved our sorry little asses with his most important formula that says that sinusoids *are* exponentials making differentiation, and shifting all come out to be equivalent to scaling. hurray!! but we can't cheer in the language of only real numbers. complex numbers and variable are not synonymous with complicated numbers and variables. r b-j