complex numbers

[xah]

#python supports complex numbers.
# 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
(e-mail address removed)
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

 

[Alfred Z. Newmane]

#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]

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.

#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
[...]

jue

 

[Anno Siegel]

[reply moved to bottom into context]

#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]

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.

I really like Python's notion of having just one data type: the duck.

 

[Anno Siegel]

[reply moved into context]

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:escriptive, 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?

 

[It's me]

And I have always been happy that FORTRAN supports them.


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]

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.

 

[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:

versus

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
(e-mail address removed)

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

 

[It's me]

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]

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?

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.

 

[It's me]

Precisely. One have to convert complex number into vectors, and vector of
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.

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?

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.

 

[Robert Kern]

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?

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.

--
Robert Kern
(e-mail address removed)

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

 

[Terry Reedy]

Precisely. One have to convert complex number into vectors, and vector
of
complex numbers into vector of vectors, list of complex numbers into list
of
vectors, ...., you get the idea.

No, one would have a class with all the appropriate special methods
defined. This is what people did before complex was made built-in. The
advantage of builtin-ness is being able to write complex literals: 1 + 1j,
etc, instead of Complex(1,1). This and speed were two reasons to make
complex numbers builtin.

The new decimal type, in spite of being builtin (written in C), has the
same 'problem' because decimal literals were alread being converted to
binary floating point. Perhaps some day we might have 1.23d to indicate
conversion to decimal instead. Or perhaps 1.23 will become a decimal and
1.23f a float.

Terry J. Reedy

 

[Carl Banks]

The world would come to a halt if all of a sudden nobody understands complex
numbers anymore.

Actually, it would oscillate out of control.

 

[Scott David Daniels]

The reason for making complex a builtin is _not_ to ease a single
program, but to create a convention allowing different modules
which operate on complex numbers to communicate.

-Scott David Daniels
(e-mail address removed)

 

[Antoon Pardon]

Precisely. One have to convert complex number into vectors, and vector of
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.