rkern at ucsd.edu
Tue Jan 11 18:16:56 EST 2005
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:
>>> complex(5, 1)
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
rkern at ucsd.edu
"In the fields of hell where the grass grows high
Are the graves of dreams allowed to die."
-- Richard Harter
More information about the Python-list