OT Complex analysis book recommendation?

This one has been a de facto standard intro for engineers for the past 100 years- you can pick up a used one for a buck:

I was taught complex analysis out of Levinson and Redheffer, which was a pretty good book.

Make sure your protege' doesn't skip the boring stuff at the beginning about analyticity, directional derivatives, and the Cauchy-Riemann equations. The time-honoured two-dimensional fluid flow application that's always in the Chapter 1 problems is helpful here.

It's amazing how many people try to do things like integrating arg(z) or |z| in the complex plane.

Cheers

Phil Hobbs

How deep into the application of the z transform do you want to go?

For a functional knowledge that's good enough to solve most problems in controls and signal processing, you can get by with some hand-waving and a few ground rulz.

Granted, that's not where you want to leave it if you're doing it all the time -- but there's a hell of a lot of DSP practitioners who escaped from school with a perfectly useful grounding in DSP and who never took a class in complex analysis.

Useful, but not as useful for keeping up to date. The whole point of school is to learn stuff that's hard to pick up on your own. That's why I continued in physics in grad school even though my work is mostly gizmo-building.

Cheers

Phil Hobbs

Thanks Phil and Fred for the two recommendations - I will buy them both.

For DSP problems I could probably teach all someone would need to know about Z-transforms in a couple of hours. I guess that's why there's only a short chapter on them in most signal processing texts.

I use them in an ultrasonic transducer design/modeling application. I wrote the core of this app about 30 years ago in Fortran* - but the fellow I had earmarked to extend this code is now having second thoughts in working with a *dead* language. Sometimes I despair at the nonsense that students are told at University. I first heard the dead language comment back in the 70's, yet it's still a very popular language in finance, physics (especially geophysics) and other number crunching applications.

What's wrong with integrating those functions in the complex plane? IIRC the integral of a complex function is just a line integral.

So long as on the path of integration the function is continuous, and the path length is finite...

Re-read your complex analysis course notes. ;)

They aren't analytic functions, so their derivatives don't exist, and none of the nice contour integration theorems apply.

Cheers

Phil Hobbs

|z| is complex differentiable only at 0, and nowhere holomorphic. So you're correct, none of the nice contour integration theorems like Cauchy's integral theorem will work.

But it's not clear at all to me that a function not being holomorphic on C or some subset of C implies non-integrability in the general sense. In C differentiability -> continuity, but even though |z| is not differentiable except at 0, it's certainly continuous and bounded on the entirety of the complex plane.

The requirement in the general sense may only be that the complex function is continuous and bounded on some domain, and that the path itself is C^1 differentiable with finite length.

In complex analysis, as in real analysis, "differentiable" means that a small change dz makes a small change in f(z), _proportional to dz_.

A corollary is that if you choose dz = i delta (delta assumed real), then if f(z) is differentiable, the line between f(z+ i delta) and f(z) has to be orthogonal to the line between f(z + delta) and f(z). The Cauchy-Riemann equations express this exact property, i.e. analyticity.

Arg(z) and |z| are purely real everywhere, so a displacement dz in any direction has to produce a purely real change, and so the C-R equations are not satisfied anywhere. The functions are therefore nowhere differentiable, and nowhere analytic.

Well, if by "general sense", you mean "some sense that I'm just making up", you're probably right. If you take R**2 and re-label it as C, then do R**2-style math on it, you'll get R**2 results, for sure. If that's your point, I agree, but it's certainly beside mine.

The usual reason for using C is that there are remarkably powerful theorems that help, as long as f(z) is analytic in some useful neighbourhood. Otherwise it's a waste of effort.

It isn't bounded, but in any case that's entirely irrelevant. In complex analysis, z is a single number. If you want to integrate arctan(y/x) or sqrt(x**2+y**2) along some path in R**2, you sure can, but that's not the same thing. You can relabel it as C if you like, but it doesn't change anything really.

Nope. You can do integrals on nondifferentiable paths and on infinite lengths--it's done all the time. Perhaps the most common contour of integration in applications is the real line plus an indefinitely large semicircle, plus maybe some indefinitely small circular loops to go round singularities.

The error of trying to do contour integration on some function that one assumes is analytic--but isn't--is quite common, which is why I emphasized to the OP that his protege' should not neglect Chapter 1 on the Cauchy-Riemann equations and so forth.

Cheers

Phil Hobbs

I think what I was trying to get at with "requirement" above is that it's my recollection that is a _sufficient_ condition for integrability, but not a _necessary_ condition.

The technique you describe with the semicircles is what you'd use if you were going to use contour integration to evaluate the integral of sin(x)/x on the real line from infinity to infinity, keeping in mind you have to use the appropriate substitution for sin(z), since sin(z) blows up at infinity.

But there are easier ways to do that one, like noting that the integrand is even, and then the trick that the integral from 0 to inf of f(x)/x = the integral from 0 to inf of the Laplace transform f(s)/s...

I admit I've forgotten a lot of complex analysis since integral transforms are usually my go-to tool these days...

The easiest way to check these days is to just bang into Wolfram Alpha "poles of f(z)" and it will likely either say "f(z) is entire", or return a finite number of poles, in which case the function is meromorphic.

If it's not one of those cases I ain't really want to deal with it...

Oughtn't that be 'almost everywhere differentiable, and nowhere analytic'?

The derivatives are very useful for error propogation calculations...

Tell him that if he converts it to Cobol he'll have an assured career -- that "dead" language is alive and kicking, and needs live bodies to program in it now that the boomers are aging out of being programmers.

The partial derivatives df/dx and df/dy exist except at the origin, but the complex derivative doesn't exist anywhere.

The partials are what you use in error propagation calculations.

Cheers

Phil Hobbs

I know quite a few engineers who went to work in the city of London in the mid 80's as programmers. They all made enough money to be able to retire within 10 years. Wish I had done that.

Well, a _job_, anyway. Personally I'd rather dig ditches. Pascal and Verilog are too verbose for my taste, and I can't even imagine coding in COBOL.

Cheers

Phil Hobbs

Verilog verbose - you must mean VHDL?

I've been learning Ada these last few weeks, with a view to using it for embedded ARM targets. Fantastic language - highly recommended.

Once I'm happy that the FSF version can do everything I want I'm going to use it in a Zynq based design - using Ada for the ARM together with VHDL for the logic will be pretty neat.

No, Verilog. I'd have preferred braces for delimiting blocks, for a start. VHDL is almost like COBOL, so I've never even got near it.

What do you like about it? When I looked at it many years back, my impression was that it was needlessly heavyweight. I can have bounds checking and so forth in C++ if I want.

Cheers

Phil Hobbs

It'd give you an incentive to write good stuff. Perhaps it could be called "succinct programming".