complex numbers

[Robert Kern]

It's me wrote:
> You are focusing on computational type applications of complex numbers.  For
> those, you can do it with any languages - including machine language.  It's
> just a matter of how much headache you want.
> 
> For instance, when constructing "software lego parts" (such as the
> Matlab/Simulink type), it's very annoying that you need to know what kind of
> signal comes in and goes out.   In Malab/Simulink, for instance, you specify
> that the signal is of the "inherit" type (meaning you don't care what type
> it is - just process it).   In Python, it's of type "duck", just pass it
> on...I don't need to care if it's real or complex.   I don't need to devise
> yet another overloaded operator or function whenever I encounter a situation
> where the native language doesn't handle.

I'm not sure what you're talking about here. Python's complex numbers 
are implemented with operator overloading. Python's integers are 
implemented with operator overloading for that matter.

The only difference between having complex numbers in the standard 
library (analogous to Math::Complex, if I'm reading these posts 
correctly; I don't use Perl) and having complex numbers in the language, 
per se, is the syntactical support:

   >>> 5.0+1.j

versus

   >>> complex(5, 1)

That's *it*.

Okay, on reflection, there's a little bit more to it: since complex 
objects come as part of the interpreter, writing C extensions that use 
complex objects is a little simpler. You don't have to include special 
header files and make sure the correct module is imported before using 
complex objects in the C code (like you have to do with Numeric, for 
example).

-- 
Robert Kern
rkern at ucsd.edu

"In the fields of hell where the grass grows high
  Are the graves of dreams allowed to die."
   -- Richard Harter