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 [EMAIL PROTECTED]
"In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter -- http://mail.python.org/mailman/listinfo/python-list
