power TypeErrors

[Terry Hancock]

On Thursday 07 November 2002 11:21 am, python-list-request at python.org wrote:
> Fernando Pérez <fperez528 at yahoo.com> writes:
> > Michael Hudson wrote:
MH> For all my mathematical leanings, I still don't really see the point
MH> of having complex numbers native to a language.

FP> Well, other than the fact that not having them is pretty
FP> much a slap in the face of everybody who does scientific
FP> computing, I guess it doesn't matter.  The fact that C lacks native
FP> complex numbers is one of the reasons many hard 
FP> core numerical computing people still frown upon it (not the
FP> only one).

MH> Really?  OK.  I was under the impression that while one used complex
MH> numbers heavily in deriving one algorithms, that when it came to
MH> implementing them they weren't an overwhelmingly helpful abstraction
MH> -- that it was often easier to split things up into arrays
MH> real_values, imag_values or something.  Maybe this is just ignorance,
MH> though.

Scientific packages that use Fourier transforms, frequently
rely on arrays of complex numbers. The general Fourier transform of 
a real array is complex-valued. We sometimes throw away the complex
part (the real part, is, I believe called a "power spectrum"), but without 
it, you cannot correctly recover the original array.

Fourier space calculations are frequently used in image processing, 
enhancement, and tomography.
 
It's also important to realize that in a rapid-prototyping tool (which is 
arguably what Python is best at), the abstract conception is the thing to 
support. A real number-crunching application will use a faster, compiled 
language to implement the "actual algorithms' you're talking about. You see 
that in Numeric or SciPy (which uses LAPACK, still implemented in Fortran!).

But the user/programmer doesn't think that way -- they use the complex-valued 
math which is the way the textbook describes it, and the way you talk about 
the problem (because that's how you're trained).  It's the human-readable 
version.

This is true in IDL, too -- users frequently use horribly memory- or CPU- 
intensive operations simply because it is *conceptually* simpler to do it 
that way. The attitude is that the saved development time is worth the extra 
run time, and you can always throw a more expensive computer at it, whereas 
trained scientists are a limiting reagent. ;-)

Of course, eventually that goes sour and you need to use an optimized 
solution, but when you're read to make that decision, you're probably ready 
to switch languages anyway (and you can use a hybrid of languages as with 
Numeric or Scipy).

FP > I'm not sure what your background is,

MH> Algebraic geometry, mainly, plus a little theoretical physics & number
MH> theory.

Yep. It's ironic that mathematicians hardly ever "do math" (by which I mean 
calculations)! It's scientists that do that  -- mostly applied physics folks: 
astronomers, chemists, geologists, engineers, and some biologists.

Mathematical and theoretical physics applications tend to stay very 
conceptual.  They manipulate equations, but they hardly ever have to actually 
plug in numbers and solve them (especially in droves).

And sometimes, it's not pretty. So we have scientific computing.

FP > but I can tell you that python is gaining _very_ strong support in
FP > scientific computing.

I also observe this.
 
MH > Given what I hear of IDL, this doesn't surprise me :)

That isn't pretty, either. ;-)

Cheers,
Terry

--
Terry Hancock ( hancock at anansispaceworks.com )
Anansi Spaceworks  http://www.anansispaceworks.com