complex numbers

Discussion in 'Python' started by xah@xahlee.org, Jan 9, 2005.

  1. Guest

    #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

    http://xahlee.org/PageTwo_dir/more.html
     
    , Jan 9, 2005
    #1
    1. Advertising

  2. 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).
    Did you check "perldoc Math::Complex"

    NAME
    Math::Complex - complex numbers and associated mathematical functions
    [...]

    jue
     
    Jürgen Exner, Jan 9, 2005
    #2
    1. Advertising

  3. J|rgen Exner wrote:
    > 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.
     
    Alfred Z. Newmane, Jan 10, 2005
    #3
  4. It's me Guest

    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.


    "Jürgen Exner" <> wrote in message
    news:Fm6Ed.3556$u47.321@trnddc09...
    > 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
    >
    >
     
    It's me, Jan 11, 2005
    #4
  5. Anno Siegel Guest

    It's me <> wrote in comp.lang.perl.misc:

    [reply moved to bottom into context]

    > "Jürgen Exner" <> wrote in message
    > news:Fm6Ed.3556$u47.321@trnddc09...
    > > 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
     
    Anno Siegel, Jan 11, 2005
    #5
  6. It's me Guest

    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" <-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.
    >
    > Anno
    >
     
    It's me, Jan 11, 2005
    #6
  7. Anno Siegel Guest

    It's me <> wrote in comp.lang.perl.misc:

    [reply moved into context]

    > "Anno Siegel" <-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
     
    Anno Siegel, Jan 11, 2005
    #7
  8. Big and Blue Guest

    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.
     
    Big and Blue, Jan 11, 2005
    #8
  9. It's me Guest

    "Big and Blue" <> wrote in message
    news:...
    > 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, Jan 11, 2005
    #9
  10. It's me Guest

    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.



    "Anno Siegel" <-berlin.de> wrote in message
    news:cs17od$ag1$-Berlin.DE...

    >
    > 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
     
    It's me, Jan 11, 2005
    #10
  11. Robert Kern Guest

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


    "In the fields of hell where the grass grows high
    Are the graves of dreams allowed to die."
    -- Richard Harter
     
    Robert Kern, Jan 11, 2005
    #11
  12. It's me Guest

    "Robert Kern" <> wrote in message
    news:cs1mp9$sg9$...
    >
    > 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?
     
    It's me, Jan 12, 2005
    #12
  13. Op 2005-01-12, It's me schreef <>:
    >
    > "Robert Kern" <> wrote in message
    > news:cs1mp9$sg9$...
    >>
    >> 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
     
    Antoon Pardon, Jan 12, 2005
    #13
  14. It's me Guest

    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.



    "Antoon Pardon" <> wrote in message
    news:...
    > Op 2005-01-12, It's me schreef <>:
    > >
    > > "Robert Kern" <> wrote in message
    > > news:cs1mp9$sg9$...
    > >>
    > >> 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
     
    It's me, Jan 12, 2005
    #14
  15. Robert Kern Guest

    It's me wrote:
    > "Robert Kern" <> wrote in message
    > news:cs1mp9$sg9$...
    >
    >>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


    "In the fields of hell where the grass grows high
    Are the graves of dreams allowed to die."
    -- Richard Harter
     
    Robert Kern, Jan 12, 2005
    #15
  16. Terry Reedy Guest

    "It's me" <> wrote in message
    news:ggcFd.10634$...
    > 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
     
    Terry Reedy, Jan 12, 2005
    #16
  17. Carl Banks Guest

    It's me wrote:
    > The world would come to a halt if all of a sudden nobody understands

    complex
    > numbers anymore. :)

    Actually, it would oscillate out of control.


    --
    CARL BANKS
     
    Carl Banks, Jan 12, 2005
    #17
  18. Robert Kern wrote:
    >> Let's presume for a moment that complex is *not* a native data type in
    >> Python. How would we implement the above - cleanly?


    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
     
    Scott David Daniels, Jan 12, 2005
    #18
  19. Op 2005-01-12, It's me schreef <>:
    > 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
     
    Antoon Pardon, Jan 13, 2005
    #19
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. news.amnet.net.au
    Replies:
    1
    Views:
    605
    =?UTF-8?b?TMSByrtpZSBUZWNoaWU=?=
    Apr 13, 2004
  2. oulan bator
    Replies:
    29
    Views:
    1,182
    Chris Uppal
    Dec 4, 2005
  3. Stanimir Stamenkov
    Replies:
    2
    Views:
    795
    Stanimir Stamenkov
    Oct 25, 2005
  4. Robert Mark Bram
    Replies:
    0
    Views:
    718
    Robert Mark Bram
    Feb 4, 2007
  5. Kottiyath

    How complex is complex?

    Kottiyath, Mar 18, 2009, in forum: Python
    Replies:
    22
    Views:
    802
Loading...

Share This Page