Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #68367 > unrolled thread

'complex' function with string argument.

Back to article view | Back to comp.lang.python

Contents

  'complex' function with string argument. Jayanth Koushik <jnkoushik@gmail.com> - 2014-03-15 09:26 -0700
    Re: 'complex' function with string argument. Mark H Harris <harrismh777@gmail.com> - 2014-03-17 11:18 -0500
      Re: 'complex' function with string argument. Chris Angelico <rosuav@gmail.com> - 2014-03-18 04:03 +1100
        Re: 'complex' function with string argument. Marko Rauhamaa <marko@pacujo.net> - 2014-03-17 20:15 +0200
          Re: 'complex' function with string argument. Ian Kelly <ian.g.kelly@gmail.com> - 2014-03-17 12:28 -0600
          Re: 'complex' function with string argument. Chris Angelico <rosuav@gmail.com> - 2014-03-18 05:59 +1100
            Re: 'complex' function with string argument. Marko Rauhamaa <marko@pacujo.net> - 2014-03-17 21:22 +0200
              Re: 'complex' function with string argument. Chris Angelico <rosuav@gmail.com> - 2014-03-18 06:32 +1100
              Re: 'complex' function with string argument. Steven D'Aprano <steve@pearwood.info> - 2014-03-18 04:08 +0000
        Re: 'complex' function with string argument. Mark H Harris <harrismh777@gmail.com> - 2014-03-17 13:20 -0500
      Re: 'complex' function with string argument. Steven D'Aprano <steve@pearwood.info> - 2014-03-18 04:52 +0000
        Re: 'complex' function with string argument. Chris Angelico <rosuav@gmail.com> - 2014-03-18 15:59 +1100
        Re: 'complex' function with string argument. Mark H Harris <harrismh777@gmail.com> - 2014-03-18 11:14 -0500
          Re: 'complex' function with string argument. wxjmfauth@gmail.com - 2014-03-19 00:30 -0700
            Re: 'complex' function with string argument. Marko Rauhamaa <marko@pacujo.net> - 2014-03-19 10:51 +0200
              Re: 'complex' function with string argument. wxjmfauth@gmail.com - 2014-03-19 02:52 -0700
                Re: 'complex' function with string argument. Marko Rauhamaa <marko@pacujo.net> - 2014-03-19 12:09 +0200
                  Re: 'complex' function with string argument. Ian Kelly <ian.g.kelly@gmail.com> - 2014-03-19 04:33 -0600
                    Re: 'complex' function with string argument. Marko Rauhamaa <marko@pacujo.net> - 2014-03-19 12:53 +0200
                      Re: 'complex' function with string argument. Ian Kelly <ian.g.kelly@gmail.com> - 2014-03-19 13:35 -0600
                  Re: 'complex' function with string argument. Skip Montanaro <skip@pobox.com> - 2014-03-19 06:04 -0500
                    Re: 'complex' function with string argument. wxjmfauth@gmail.com - 2014-03-19 07:35 -0700
                  Re: 'complex' function with string argument. Ian Kelly <ian.g.kelly@gmail.com> - 2014-03-19 12:45 -0600
    Re: 'complex' function with string argument. Mark Dickinson <mdickinson@enthought.com> - 2014-03-17 17:55 +0000
    Re: 'complex' function with string argument. Terry Reedy <tjreedy@udel.edu> - 2014-03-17 18:06 -0400
    Re: 'complex' function with string argument. Skip Montanaro <skip@pobox.com> - 2014-03-17 18:59 -0500
    Re: 'complex' function with string argument. Chris Angelico <rosuav@gmail.com> - 2014-03-18 11:16 +1100
    Re: 'complex' function with string argument. Skip Montanaro <skip@pobox.com> - 2014-03-17 20:07 -0500
    Re: 'complex' function with string argument. Christian Gollwitzer <auriocus@gmx.de> - 2014-03-18 08:04 +0100
      Re: 'complex' function with string argument. Chris Angelico <rosuav@gmail.com> - 2014-03-18 18:11 +1100
      Re: 'complex' function with string argument. Steven D'Aprano <steve@pearwood.info> - 2014-03-18 08:00 +0000
        Re: 'complex' function with string argument. Christian Gollwitzer <auriocus@gmx.de> - 2014-03-18 09:21 +0100
          Re: 'complex' function with string argument. Marko Rauhamaa <marko@pacujo.net> - 2014-03-18 16:00 +0200

Page 2 of 2 — ← Prev page 1 [2]

#68548

On Wed, Mar 19, 2014 at 5:33 AM, Ian Kelly <ian.g.kelly@gmail.com> wrote:
> When is it ever useful though?

About as often as int(0), float(0), or float(0.0) which all work as
expected, though probably don't turn up in a lot of code.

Skip

[toc] | [prev] | [next] | [standalone]

#68555

Le mercredi 19 mars 2014 12:04:06 UTC+1, Skip Montanaro a écrit :
> On Wed, Mar 19, 2014 at 5:33 AM, Ian Kelly <ian.g.kelly@gmail.com> wrote:
> 
> > When is it ever useful though?
> 
> 
> 
> About as often as int(0), float(0), or float(0.0) which all work as
> 
> expected, though probably don't turn up in a lot of code.
> 
> 
> 
> Skip

Your comment is equivalent to this:

>>> complex(1+2.0j)
(1+2j)
>>> complex(0+0.0j)
0j

Both, the constructor and the docstring, are not so clean.

What to say about the __repr__ ? Are not a and b
supposed to be floats? (elements of R)

>>> 0
0
>>> 0.0
0.0
>>> 0j
0j
>>> 1.0 + 2.0j
(1+2j)
>>> 1.
1.0
>>> 1
1
>>> (1 + 2.0j).real
1.0
>>> type((1 + 2.0j).real)
<class 'float'>

jmf

[toc] | [prev] | [next] | [standalone]

#68560

On Wed, Mar 19, 2014 at 5:04 AM, Skip Montanaro <skip@pobox.com> wrote:
> On Wed, Mar 19, 2014 at 5:33 AM, Ian Kelly <ian.g.kelly@gmail.com> wrote:
>> When is it ever useful though?
>
> About as often as int(0), float(0), or float(0.0) which all work as
> expected, though probably don't turn up in a lot of code.

The analogous call to those is complex(1+2j), which I have no problem
with, not complex(1+2j, 3+4j).

[toc] | [prev] | [next] | [standalone]

#68443

Jayanth Koushik <jnkoushik <at> gmail.com> writes:

> "Note: When converting from a string, the string must not contain whitespace
> around the central + or - operator. For example, complex('1+2j') is fine, but
> complex('1 + 2j') raises ValueError."
> 
> Why is this so?

See http://bugs.python.org/issue9574 for a bit more context.  To begin with,
it's not at all clear what *should* be allowed.  If "1 + 2j" is valid, what
about "+ 2j"?  How about "+ 2"?  What about things like "+1.0 + -2.3j"?
Ultimately, I closed that issue because the proposed change seemed like
unnecessary code churn, and there wasn't a clear consensus that the change was
desirable (or even what that change should be).  If it ain't broke, etc.

-- 
Mark

[toc] | [prev] | [next] | [standalone]

#68465

On 3/17/2014 1:55 PM, Mark Dickinson wrote:
> Jayanth Koushik <jnkoushik <at> gmail.com> writes:
>
>> "Note: When converting from a string, the string must not contain whitespace
>> around the central + or - operator. For example, complex('1+2j') is fine, but
>> complex('1 + 2j') raises ValueError."
>>
>> Why is this so?
>
> See http://bugs.python.org/issue9574 for a bit more context.  To begin with,
> it's not at all clear what *should* be allowed.  If "1 + 2j" is valid, what
> about "+ 2j"?  How about "+ 2"?  What about things like "+1.0 + -2.3j"?
> Ultimately, I closed that issue because the proposed change seemed like
> unnecessary code churn, and there wasn't a clear consensus that the change was
> desirable (or even what that change should be).  If it ain't broke, etc.

I was not nosy on that issue, but  I agree with 'as is', along with no 
space in Franction("1/2"). Mathematicians genearally write both without 
spaces.

-- 
Terry Jan Reedy

[toc] | [prev] | [next] | [standalone]

#68467

On Mon, Mar 17, 2014 at 5:06 PM, Terry Reedy <tjreedy@udel.edu> wrote:
> Mathematicians genearally write both without spaces.

Mathematicians also have a tendency to use single letter variables and
often escape into non-ASCII character sets as well. <wink>

Perhaps it's worth pointing out that pylint complains about most/many
infix operations if you don't surround the operator with white space.
And, complex expressions work just fine with white space around the
operator:

>>> 1 + 2j
(1+2j)

Personally, I'm agnostic to the proposed change. I don't use complex
numbers in my work, and I suspect that creating complex numbers from
strings is an extremely small corner case.

Skip

[toc] | [prev] | [next] | [standalone]

#68469

On Tue, Mar 18, 2014 at 10:59 AM, Skip Montanaro <skip@pobox.com> wrote:
> Perhaps it's worth pointing out that pylint complains about most/many
> infix operations if you don't surround the operator with white space.

IMO that's excessive. Not every infix operator needs whitespace.

ChrisA

[toc] | [prev] | [next] | [standalone]

#68475

On Mon, Mar 17, 2014 at 7:16 PM, Chris Angelico <rosuav@gmail.com> wrote:
> On Tue, Mar 18, 2014 at 10:59 AM, Skip Montanaro <skip@pobox.com> wrote:
>> Perhaps it's worth pointing out that pylint complains about most/many
>> infix operations if you don't surround the operator with white space.
>
> IMO that's excessive. Not every infix operator needs whitespace.

I wasn't suggesting it was the only way things could be done. Just
pointing out that there is enough common practice out there to suggest
that white space around infix operators is often the preferred way of
doing things. Quoting from PEP 8:

If operators with different priorities are used, consider adding
whitespace around the operators with the lowest priority(ies). Use
your own judgment; however, never use more than one space, and always
have the same amount of whitespace on both sides of a binary operator.

Yes:

i = i + 1
submitted += 1
x = x*2 - 1
hypot2 = x*x + y*y
c = (a+b) * (a-b)

...

My point is that accommodating white space around the + or - sign
isn't altogether unreasonable.

Maybe PEP 8 needs to be tweaked with an example of good complex
literal practice?

Skip

[toc] | [prev] | [next] | [standalone]

#68486

Am 15.03.14 17:26, schrieb Jayanth Koushik:
> This is regarding the inbuilt 'complex' function. The python docs
> say: "Note: When converting from a string, the string must not
> contain whitespace around the central + or - operator. For example,
> complex('1+2j') is fine, but complex('1 + 2j') raises ValueError."

It's funny that you ask this question exactly now; because I'm currently 
implementing a compiler for a small language that understands complex 
numbers. As others have explained, the basic issue is the question how 
to parse an expression like

	1+2i*3

is it "complex(1+2i) times 3" or is it sum of 1 and product of complex 
2i and 3? The answer that python does it by parsing imaginary literals 
and then combining them back using peephole optimization was helpful, 
thanks for that!

	Christian

[toc] | [prev] | [next] | [standalone]

#68488

On Tue, Mar 18, 2014 at 6:04 PM, Christian Gollwitzer <auriocus@gmx.de> wrote:
> As others have explained, the basic issue is the question how to parse an
> expression like
>
>         1+2i*3
>
> is it "complex(1+2i) times 3" or is it sum of 1 and product of complex 2i
> and 3?

The only way to have it be the former would be to mandate that all
complex literals have both parts, and you'd still lose clarity. You'd
probably want to have some other symbol rather than + in there, to
emphasize the connection:

1_2j
1_--2j # Negative imaginary component

Otherwise, yeah, do what Python does and have imaginary literals only.

ChrisA

[toc] | [prev] | [next] | [standalone]

#68495

On Tue, 18 Mar 2014 08:04:44 +0100, Christian Gollwitzer wrote:

> Am 15.03.14 17:26, schrieb Jayanth Koushik:
>> This is regarding the inbuilt 'complex' function. The python docs say:
>> "Note: When converting from a string, the string must not contain
>> whitespace around the central + or - operator. For example,
>> complex('1+2j') is fine, but complex('1 + 2j') raises ValueError."
> 
> It's funny that you ask this question exactly now; because I'm currently
> implementing a compiler for a small language that understands complex
> numbers. As others have explained, the basic issue is the question how
> to parse an expression like
> 
> 	1+2i*3
> 
> is it "complex(1+2i) times 3" 

Putting my mathematician's hat on, I would say *absolutely not*.

> or is it sum of 1 and product of complex 2i and 3? 

This one. Multiplication has higher precedence than addition, so 1+2i*3 
has to be evaluated as 1+(2i*3).


-- 
Steve

[toc] | [prev] | [next] | [standalone]

#68497

Hi Steven,

Am 18.03.14 09:00, schrieb Steven D'Aprano:
> On Tue, 18 Mar 2014 08:04:44 +0100, Christian Gollwitzer wrote:
>
>> Am 15.03.14 17:26, schrieb Jayanth Koushik:
>>> This is regarding the inbuilt 'complex' function. The python docs say:
>>> "Note: When converting from a string, the string must not contain
>>> whitespace around the central + or - operator. For example,
>>> complex('1+2j') is fine, but complex('1 + 2j') raises ValueError."
>>
>> It's funny that you ask this question exactly now; because I'm currently
>> implementing a compiler for a small language that understands complex
>> numbers. As others have explained, the basic issue is the question how
>> to parse an expression like
>>
>> 	1+2i*3
>>
>> is it "complex(1+2i) times 3"
>
> Putting my mathematician's hat on, I would say *absolutely not*.
>
>> or is it sum of 1 and product of complex 2i and 3?
>
> This one. Multiplication has higher precedence than addition, so 1+2i*3
> has to be evaluated as 1+(2i*3).

The question was not whether the expression should be interpreted the 
first way, I'm sorry for being unclear. The question was how to 
implement this in a compiler. Because if you implement complex literals 
in the tokenizer, you would end up with the tokens of the first 
interpretation. But if you implement as imaginary literals, then your 
parse tree for "1+2i" ends up as a sum of a real and an imaginary 
literal, instead of a complex literal. This works, but it lets your 
parse tree grow and possibly generates inefficient code. The answer I 
got here, is to parse it as a sum and let the optimizer combine it back 
into a single complex constant.


The same problem arises with unary minus, but it's less annoying because 
-(a*b) = (-a)*b.

I admit that my knowledge of compiler construction is limited, and I'm 
working on my first real-world application now. Oh, and it's not written 
in Python.

	Christian

[toc] | [prev] | [next] | [standalone]

#68504

Christian Gollwitzer <auriocus@gmx.de>:

> The same problem arises with unary minus, but it's less annoying
> because -(a*b) = (-a)*b.

  >>> -1**2
  -1


Marko

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.python

csiph-web