complex numbers
x...@xahlee.org
# append a "j" to a number and it represents the imaginary number. e.g.
# 3j means 3*i.
#(3,4) can be written as 3+4j
#another way to write is is
#complex(3,4)
#arithmetic operations can be applied normally.
# to get the real part, imaginary part, or length, one can do
a=complex(3,4)
print a.real
print a.imag
print abs(a)
print complex(3,4)+5+6j
----------------
# Perl doesn't support complex numbers. But there are packages that
supports it.
Xah
x...@xahlee.org
http://xahlee.org/PageTwo_dir/more.html
Jürgen Exner
> #python supports complex numbers.
[...]
So?
> # Perl doesn't support complex numbers. But there are packages that
> supports it.
The Math::Complex module is part of the standard installation already, no
need for any "packages" (whatever that might be).
Did you check "perldoc Math::Complex"
NAME
Math::Complex - complex numbers and associated mathematical functions
[...]
jue
Tad McClellan
> #python supports complex numbers.
> # Perl doesn't support complex numbers.
Then you should use Python and stop Perl programming immediately!
--
Tad McClellan SGML consulting
ta...@augustmail.com Perl programming
Fort Worth, Texas
Alfred Z. Newmane
> x...@xahlee.org wrote:
>> #python supports complex numbers.
> [...]
>
> So?
>
>> # Perl doesn't support complex numbers. But there are packages that
>> supports it.
>
> The Math::Complex module is part of the standard installation
> already, no need for any "packages" (whatever that might be).
'package' is a keyword, you should know this :-) Thats an important part
of most modules.
Actually it seems a lot of people use 'module' and 'package'
interchangably, both refering to libraries, if you will, the one can
include in a script, or another package.
It's me
natively supported data type is a big advantage. Non-native add-ons are not
sufficient and lead to very awkward program code.
"Jürgen Exner" <jurg...@hotmail.com> wrote in message
news:Fm6Ed.3556$u47.321@trnddc09...
> x...@xahlee.org wrote:
> > #python supports complex numbers.
> [...]
>
> So?
>
The world would come to a halt if all of a sudden nobody understands complex
numbers anymore. :-)
Anno Siegel
[reply moved to bottom into context]
> "Jürgen Exner" <jurg...@hotmail.com> wrote in message
> news:Fm6Ed.3556$u47.321@trnddc09...
> > x...@xahlee.org wrote:
> > > #python supports complex numbers.
> > [...]
> >
> > So?
> >
>
> The world would come to a halt if all of a sudden nobody understands complex
> numbers anymore. :-)
>
> > > # Perl doesn't support complex numbers. But there are packages that
> > > supports it.
> >
> > The Math::Complex module is part of the standard installation already, no
> > need for any "packages" (whatever that might be).
> > Did you check "perldoc Math::Complex"
> >
> > NAME
> > Math::Complex - complex numbers and associated mathematical functions
> > [...]
> For those of us that works with complex numbers, having complex number as a
> natively supported data type is a big advantage. Non-native add-ons are not
> sufficient and lead to very awkward program code.
Like this?
use Math::Complex;
my $z = sqrt( -1);
print 1 + $z, "\n"; # prints "1+i"
Operator overloading makes it possible to work with complex numbers as if
they were a native data type.
Anno
It's me
have to be aware of the complex type *everywhere* you go and that's very
annoying and error prone. I've been the works with C++, and later with
Modelica. I am very happy that Python included *native* complex number
support.
I really like Python's notion of having just one data type: the duck.
"Anno Siegel" <anno...@lublin.zrz.tu-berlin.de> wrote in message
news:cs145l$8d6
<snip>
Anno Siegel
[reply moved into context]
> "Anno Siegel" <anno...@lublin.zrz.tu-berlin.de> wrote in message
> news:cs145l$8d6
>
> <snip>
>
> >
> > Like this?
> >
> > use Math::Complex;
> >
> > my $z = sqrt( -1);
> > print 1 + $z, "\n"; # prints "1+i"
> >
> > Operator overloading makes it possible to work with complex numbers as if
> > they were a native data type.
> Operator overloading (and function overloading) helps but not enough. You
> have to be aware of the complex type *everywhere* you go and that's very
> annoying and error prone. I've been the works with C++, and later with
> Modelica. I am very happy that Python included *native* complex number
> support.
What kind of awareness do you mean?
There are some operations (as comparison) that work for reals, but not
for complex numbers. If you want your program to run with complex input,
you have to avoid such operations, whether the data type is native or not.
What other considerations are there? A typical numeric program should
just run and give complex output when fed complex input. I made the
experiment with the Perl module Statistics::Descriptive, which was
certainly written without concern for complex input, and it works without
a hitch. I'm not sure if the (complex) variance of several complex
numbers is a reasonably interpretable quantity, but I'm certain the
maths is done right. What else do you want?
Anno
Big and Blue
>
> I am very happy that Python included *native* complex number
> support.
And I have always been happy that FORTRAN supports them.
> I really like Python's notion of having just one data type: the duck.
So have you considered using Python for your problem?
--
Just because I've written it doesn't mean that
either you or I have to believe it.
It's me
"Big and Blue" <No...@dsl.pipex.com> wrote in message
news:6-Cdnfjyqs6...@pipex.net...
> It's me wrote:
> >
> > I am very happy that Python included *native* complex
number
> > support.
>
> And I have always been happy that FORTRAN supports them.
>
> > I really like Python's notion of having just one data type: the duck.
>
> So have you considered using Python for your problem?
>
Yes, over the holiday, I wrote a somewhat complex program using Python -
just so I can apply what I have learned so far. It's a joy to use. I was
able to finished the program in a fraction of the time it used to take me in
Fortran (and later C).
It's me
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.
"Anno Siegel" <anno...@lublin.zrz.tu-berlin.de> wrote in message
news:cs17od$ag1$1...@mamenchi.zrz.TU-Berlin.DE...
Robert Kern
> 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
rk...@ucsd.edu
"In the fields of hell where the grass grows high
Are the graves of dreams allowed to die."
-- Richard Harter
It's me
"Robert Kern" <rk...@ucsd.edu> wrote in message
news:cs1mp9$sg9$1...@news1.ucsd.edu...
>
> That's *it*.
So, how would you overload an operator to do:
With native complex support:
def twice(a):
return 2*a
print twice(3+4j), twice(2), twice("abc")
Let's presume for a moment that complex is *not* a native data type in
Python. How would we implement the above - cleanly?
Antoon Pardon
I suppose in the same way as (graphic) points and vectors can be
implemented cleanly.
A few years back I had written a Vector class in python, just
to get an understanding of how things worked. It worked without
a problem with your twice function.
>>> Vec(1.0,2.0)
Vector[1.0, 2.0]
>>> def twice(a):
... return 2 * a
...
>>> twice(Vec(1.0,2.0))
Vector[2.0, 4.0]
>>>
I suppose what can be done with a vector class could have been
done with a complex class should complex numbers not have been
native to python.
--
Antoon Pardon
It's me
complex numbers into vector of vectors, list of complex numbers into list of
vectors, ...., you get the idea.
And my code no longer look like the equation I have on paper...
Like I said, I've travelled down that path before with C++ and Modelica.
It gets ugly.
Anyway.
"Antoon Pardon" <apa...@forel.vub.ac.be> wrote in message
news:slrncu9mmo....@rcpc42.vub.ac.be...
Robert Kern
The way it's implemented now. See the file Object/complexobject.c for
details. Numeric operations on ints, longs, floats, and complex numbers
are all implemented using operator overloading.
There's nothing special about the complex object. One can even remove it
from the language quite easily. Some of the embedded versions of Python
have in fact done so.
Carl Banks
It's me wrote:
> The world would come to a halt if all of a sudden nobody understands
complex
> numbers anymore. :-)
--
CARL BANKS
Antoon Pardon
> complex numbers into vector of vectors, list of complex numbers into list of
> vectors, ...., you get the idea.
Wrong. My vector example was an illustration that you can build a user
class that behaves as you want. Python doesn't has a vecor class build
in. Yet I could write a vector class that behaved as you wished with
regard to your twice function.
What can be done for a vector class can be done again for a complex
class, no need to use the vector class for complex numbers.
> And my code no longer look like the equation I have on paper...
>
> Like I said, I've travelled down that path before with C++ and Modelica.
> It gets ugly.
Ugly, where? In the implementation of the class? That is possible.
In the use of the class, as you suggest by writing that
your code no longer looks like the equation you have on paper.
In that case I suggest the class was poorly done.
--
Antoon Pardon