#### Do you have a question? Post it now! No Registration Necessary. Now with pictures!

**posted on**

January 9, 2005, 6:36 am

# 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

xah@xahlee.org

http://xahlee.org/PageTwo_dir/more.html

## Re: complex numbers

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

## Re: complex numbers

> xah@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.

## Re: complex numbers

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.

> xah@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

> [...]

>

> jue

>

>

natively supported data type is a big advantage. Non-native add-ons are not

sufficient and lead to very awkward program code.

> xah@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

> [...]

>

> jue

>

>

## Re: complex numbers

[reply moved to bottom into context]

> > xah@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

## Re: complex numbers

Operator overloading (and function overloading) helps but not enough. You

have to be aware of the complex type

annoying and error prone. I've been the works with C++, and later with

Modelica. I am very happy that Python included

support.

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

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.

>

> Anno

>

have to be aware of the complex type

***everywhere***you go and that's veryannoying and error prone. I've been the works with C++, and later with

Modelica. I am very happy that Python included

***native***complex numbersupport.

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

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.

>

> Anno

>

## Re: complex numbers

[reply moved into context]

> 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

## Re: complex numbers

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.

>

> 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

## Re: complex numbers

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

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@ucsd.edu

"In the fields of hell where the grass grows high

Are the graves of dreams allowed to die."

-- Richard Harter

> 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@ucsd.edu

"In the fields of hell where the grass grows high

Are the graves of dreams allowed to die."

-- Richard Harter

## Re: complex numbers

>

> 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?

## Re: complex numbers

>

>>

>> 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?

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

>>

>> 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?

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

## Re: complex numbers

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.

> >

> >>

> >> 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?

>

>

> 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

## Re: complex numbers

> 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.

--

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

## Re: complex numbers

It's me wrote:

>

>>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?

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

rkern@ucsd.edu

"In the fields of hell where the grass grows high

Are the graves of dreams allowed to die."

-- Richard Harter

>

>>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?

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

rkern@ucsd.edu

"In the fields of hell where the grass grows high

Are the graves of dreams allowed to die."

-- Richard Harter

## Re: complex numbers

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?

--

Just because I've written it doesn't mean that

either you or I have to believe it.

>

> 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.

## Re: complex numbers

> 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).

#### Site Timeline

- » FAQ 1.3 Which version of Perl should I use?
- — Next thread in » PERL Discussions

- » unicode support
- — Previous thread in » PERL Discussions

- » s suffix question
- — Newest thread in » PERL Discussions

- » Dell Battery Slice LED codes
- — The site's Newest Thread. Posted in » Laptop Computers Forum