Re: 'complex' function with string argument.
On Wed, Mar 19, 2014 at 4:53 AM, Marko Rauhamaa wrote: > Ian Kelly : > >> On Wed, Mar 19, 2014 at 4:09 AM, Marko Rauhamaa wrote: >>> So complex(a, b) is documented to produce a+bj when a and b are integers >>> or floats. What's more natural than saying it produces a+bj when a and b >>> are complex numbers? It's a straightforward generalization that in no >>> way violates the more limited documentation. >> >> When is it ever useful though? [...] It would be better to raise an >> exception in either of the cases above, in my opinion. > > I don't think it matters one way or another. > > Medieval mathematicians had to address an analogous issue when they had > to decide if > >x + 0 > > was meaningful. After all, adding nothing doesn't make any sense and > should raise a ValueError exception... I wasn't aware that algebra had ValueErrors. Describing an operation as "undefined" isn't the same thing. Anyway, if mathematicians discover that the definitions of the past were flawed or incomplete, then they redefine them. Case in point, if we were still using Brahmagupta's rules for zero, then 0/0 would be 0. Python though has backward compatibility to worry about. Because of this, it is much simpler to add wanted behavior than to remove unwanted behavior. If an operation can be generalized but the generalization has no apparent use case, it *may* be better to disallow it, with the possibility of adding it later when a user pops up and says "Hey, this would actually be useful to me", than to allow it from the beginning, and then have no option to remove it later when it turns out to be merely a nuisance. Compare for example the 2-argument int constructor. Normally this is meant to be called like int("42", 13), where it will interpret the digits passed as base 13 and return 54. We might generalize that and say that if the user passes int(42, 13), it should also return 54, seeing that the repr of 42 provides the digits "42". It is more likely though that this call merely indicates a bug in the user's code, and fortunately in this case what Python actually does is to raise a TypeError. Anyway, curious though this tangent is, further discussion is unlikely to produce any useful outcome, so I'll just leave it there. -- https://mail.python.org/mailman/listinfo/python-list
Re: 'complex' function with string argument.
On Wed, Mar 19, 2014 at 5:04 AM, Skip Montanaro wrote: > On Wed, Mar 19, 2014 at 5:33 AM, Ian Kelly 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). -- https://mail.python.org/mailman/listinfo/python-list
Re: 'complex' function with string argument.
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 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) jmf -- https://mail.python.org/mailman/listinfo/python-list
Re: 'complex' function with string argument.
On Wed, Mar 19, 2014 at 5:33 AM, Ian Kelly 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 -- https://mail.python.org/mailman/listinfo/python-list
Re: 'complex' function with string argument.
Ian Kelly : > On Wed, Mar 19, 2014 at 4:09 AM, Marko Rauhamaa wrote: >> So complex(a, b) is documented to produce a+bj when a and b are integers >> or floats. What's more natural than saying it produces a+bj when a and b >> are complex numbers? It's a straightforward generalization that in no >> way violates the more limited documentation. > > When is it ever useful though? [...] It would be better to raise an > exception in either of the cases above, in my opinion. I don't think it matters one way or another. Medieval mathematicians had to address an analogous issue when they had to decide if x + 0 was meaningful. After all, adding nothing doesn't make any sense and should raise a ValueError exception... Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: 'complex' function with string argument.
On Wed, Mar 19, 2014 at 4:09 AM, Marko Rauhamaa wrote: > wxjmfa...@gmail.com: > >> Le mercredi 19 mars 2014 09:51:20 UTC+1, Marko Rauhamaa a écrit : >>> wxjmfa...@gmail.com: >>> complex(2, 1+1j) >>> > (1+1j) >>> >>> I find it neat, actually. >> > # tricky: yes, neat: no > complex(1+1j, 2) >> (1+3j) > > So complex(a, b) is documented to produce a+bj when a and b are integers > or floats. What's more natural than saying it produces a+bj when a and b > are complex numbers? It's a straightforward generalization that in no > way violates the more limited documentation. When is it ever useful though? I only see a use for passing a as complex if b is omitted, and I don't see any use for passing b as complex. If there's no use case, then it's just a confusing edge case that will catch unsuspecting programmers who thought the data they were passing in was real-valued when actually it wasn't. It would be better to raise an exception in either of the cases above, in my opinion. If you really want to form a complex a+bj from two other complex numbers, there is always the explicit (a + b * 1j). That said, complex numbers have been around since 1.4 or so, and there's probably not much chance to change it now. -- https://mail.python.org/mailman/listinfo/python-list
Re: 'complex' function with string argument.
wxjmfa...@gmail.com: > Le mercredi 19 mars 2014 09:51:20 UTC+1, Marko Rauhamaa a écrit : >> wxjmfa...@gmail.com: >> complex(2, 1+1j) >> > (1+1j) >> >> I find it neat, actually. > # tricky: yes, neat: no complex(1+1j, 2) > (1+3j) So complex(a, b) is documented to produce a+bj when a and b are integers or floats. What's more natural than saying it produces a+bj when a and b are complex numbers? It's a straightforward generalization that in no way violates the more limited documentation. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: 'complex' function with string argument.
Le mercredi 19 mars 2014 09:51:20 UTC+1, Marko Rauhamaa a écrit : > wxjmfa...@gmail.com: > > > > > This is, in my mind, more questionable: > > > > > complex(2, 1+1j) > > > (1+1j) > > > > I find it neat, actually. > > > > > > Marko >>> # tricky: yes, neat: no >>> complex(1+1j, 2) (1+3j) >>> -- https://mail.python.org/mailman/listinfo/python-list
Re: 'complex' function with string argument.
wxjmfa...@gmail.com: > This is, in my mind, more questionable: > complex(2, 1+1j) > (1+1j) I find it neat, actually. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: 'complex' function with string argument.
z = a + b*i with a, b, elements of R z = r*exp(i*phi)with r, phi, elements of R z = [[a, -b], [b, a]] with a, b, elements of R This is, in my mind, more questionable: >>> complex(2, 1+1j) (1+1j) >>> >>> print(complex.__doc__) complex(real[, imag]) -> complex number Create a complex number from a real part and an optional imaginary part. This is equivalent to (real + imag*1j) where imag defaults to 0. jmf -- https://mail.python.org/mailman/listinfo/python-list
Re: 'complex' function with string argument.
On 3/17/14 11:52 PM, Steven D'Aprano wrote: On Mon, 17 Mar 2014 11:18:56 -0500, Mark H Harris wrote: Who knows, beats me. With respect, that's just because you would make a lousy language designer :-) Ouch;-) "How should one spell a complex number?" There is perfectly good syntax for complex numbers used by mathematicians and engineers for over a century. There is no need to invent something different just for the sake of being different: Yes: 2+3i or 2+3j Yes. my Q was rhetorical only. And for the sake of discussion, particularly on the part of the OP, to think about what one expects based on experience and common sense, as a mathematician. (that doesn't mean it will be easy for the lexical parser. "Should we use i or j ?" There are good reasons for both i and j. This one comes down to personal preference. no, not really. nobody writes, e^(jPI) + 1 = 0 Euler wants to see e^(iPI) + 1 = 0 ;-) "Should the imaginary part be set off somehow?" What do you mean "set off"? Why do you want to? Since the imaginary part can appear on its own: simply, is 2j a literal complex part? ...yes 2 j ...no In other words, there must NEVER be a space between the 2 and j. This is debatable: 3 +2jalthough, I want to see3+2j z = 2 + 3j # an expression adding 2 to 3j z = 5*3j # an expression multiplying 5 by 3j all good, well until its not How flexible should the complex constructor be? Should it bend over backwards to accept any mathematical expression that includes a complex j suffix, e.g. complex("2**3i")? I think not, I think not either. But, it is possible to have *many* constructors/ But, really, how often is this a problem? like almost never! >>> complex( 3 +2j ) (3+2j) >>> I don't know... you tell me. In both cases, the call to complex is redundant. You've already created a complex number, using syntax, then you pass it to the complex function which just returns the same number. Of course. I was merely pointing out that the constructor for 'literals' (whatever you guys mean by that) is 'different' than the consistency with the string constructor. As Chris pointed out these are two markedly different animals; one is a valid parse syntax, the other is a string constructor. But here is my point--- to the user the difference comes down to semantics, which is not really true. cf. below >>> complex('3+2j') (3+2j) >>> complex('3 +2j') Traceback (most recent call last): File "", line 1, in complex('3 +2j') ValueError: complex() arg is a malformed string Also, philosophically, C ignores white space; python does not. This was said tongue in cheek... *both* languages inconsistently observer (and ignore) white space! But, in general, white space is more important to python, and less important to C. I'm still hung up on whether I'm a lousy language designer. I guess we'll know if people use my language (or not)! I suppose they might use it even though its lousy; on the other hand, it might be too simple for folks to be able to figure it out. :) marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: 'complex' function with string argument.
Christian Gollwitzer : > The same problem arises with unary minus, but it's less annoying > because -(a*b) = (-a)*b. >>> -1**2 -1 Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: 'complex' function with string argument.
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 -- https://mail.python.org/mailman/listinfo/python-list
Re: 'complex' function with string argument.
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 -- https://mail.python.org/mailman/listinfo/python-list
Re: 'complex' function with string argument.
On Tue, Mar 18, 2014 at 6:04 PM, Christian Gollwitzer 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 -- https://mail.python.org/mailman/listinfo/python-list
Re: 'complex' function with string argument.
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 -- https://mail.python.org/mailman/listinfo/python-list
Re: 'complex' function with string argument.
On Tue, Mar 18, 2014 at 3:52 PM, Steven D'Aprano wrote: > The first is a valid identifier, the second is a syntax error. Oh > somebody please tell me it's not a valid C expression! *wink* It's not a valid C expression. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: 'complex' function with string argument.
On Mon, 17 Mar 2014 11:18:56 -0500, Mark H Harris wrote: > How should one spell a complex number? Should we use i or j ? Should the > imaginary part be set off somehow? Should literals be parsed > differently (or consistently) with correctly formed strings? Who knows, > beats me. With respect, that's just because you would make a lousy language designer :-) The answer to most of those questions should be pretty obvious, with perhaps just one that isn't clear. "How should one spell a complex number?" There is perfectly good syntax for complex numbers used by mathematicians and engineers for over a century. There is no need to invent something different just for the sake of being different: Yes: 2+3i or 2+3j No:@2|3? "Should we use i or j ?" There are good reasons for both i and j. This one comes down to personal preference. "Should the imaginary part be set off somehow?" What do you mean "set off"? Why do you want to? Since the imaginary part can appear on its own: z = 3j we cannot make "setting off" compulsory. Once you have syntax for complex numbers with an imaginary component, everything else Just Works with no additional effort: z = 2 + 3j # an expression adding 2 to 3j z = 5*3j # an expression multiplying 5 by 3j There's no need for dedicated syntax for complex numbers beyond the simple no-real-part case. You get everything else for free from basic arithmetic expressions, so there actually isn't need to parse complex literals beyond the j suffix. "Should literals be parsed differently (or consistently) with correctly formed strings?" Once you decide that complex literals should be formed from only the imaginary part, 3j, parsing literals is simple. So is passing strings: you have something that looks like a float, with a j suffix. Obviously they should parse the same. assert 1.234j == complex('1.234j') Problem solved. Well, not quite -- it would be rather limiting if the complex constructor only accepted complex numbers with an implicitly zero real part. We'd like to accept anything that repr(z) can print. Since repr(z) prints complex numbers with a + or - infix operator, the complex constructor should accept the same inside strings. How flexible should the complex constructor be? Should it bend over backwards to accept any mathematical expression that includes a complex j suffix, e.g. complex("2**3i")? I think not, since complex numbers don't display like that. Our only obligation is to parse the strings that complex.__repr__ can produce, not to parse any imaginable numeric expression. So at a minimum, complex should accept strings that look like j +j -j For the same reason that float("2") works, we should also allow strings that look like: with no j suffix. Anything else, including spaces around the + and - symbols, would be a bonus. > consider: > >>> complex( 3 + 2 j) > SyntaxError: invalid syntax That's a syntax error for the same reason that: x = 1 2 is a syntax error. Nothing to do with the + sign. It's the spaces between the 2 and the j. > >>> complex( 3 +2j ) > (3+2j) > >>> > I don't know... you tell me. In both cases, the call to complex is redundant. You've already created a complex number, using syntax, then you pass it to the complex function which just returns the same number. > >>> complex('3+2j') > (3+2j) > >>> complex('3 +2j') > Traceback (most recent call last): >File "", line 1, in > complex('3 +2j') > ValueError: complex() arg is a malformed string Personally, I would like complex to accept spaces around the + or -, as it already accepts leading and trailing spaces. But it's not a big deal. [...] > Also, philosophically, C ignores white space; python does not. C does not ignore whitespace. forwhile is not the same as for while The first is a valid identifier, the second is a syntax error. Oh somebody please tell me it's not a valid C expression! *wink* -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: 'complex' function with string argument.
On Mon, 17 Mar 2014 21:22:18 +0200, Marko Rauhamaa wrote: > Chris Angelico : > >> On Tue, Mar 18, 2014 at 5:15 AM, Marko Rauhamaa >> wrote: >>> Is "-2.0" a literal? >>> >>> What's the outcome of >>> >>>-2.0.__str__() >> >> If you mean (-2.0).__str__(), then it returns '-2.0', but that proves >> nothing. > > The point is, you don't need to "philosophize" about complex literals > when even negative numbers don't have literals in Python. But Python *does* have complex (well, imaginary to be precise) literals. The j suffix to a number makes it complex: py> type(2j) Complex numbers with both a real and imaginary component are not treated as literals: py> import ast py> ast.dump(ast.parse("2j")) 'Module(body=[Expr(value=Num(n=2j))])' py> ast.dump(ast.parse("1+2j")) 'Module(body=[Expr(value=BinOp(left=Num(n=1), op=Add(), right=Num(n=2j)))])' and in recent versions, the peephole optimizer optimizes them: py> from dis import dis py> dis("1+2j") 1 0 LOAD_CONST 2 ((1+2j)) 3 RETURN_VALUE -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: 'complex' function with string argument.
On Mon, Mar 17, 2014 at 7:16 PM, Chris Angelico wrote: > On Tue, Mar 18, 2014 at 10:59 AM, Skip Montanaro 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 -- https://mail.python.org/mailman/listinfo/python-list
Re: 'complex' function with string argument.
On Tue, Mar 18, 2014 at 10:59 AM, Skip Montanaro 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 -- https://mail.python.org/mailman/listinfo/python-list
Re: 'complex' function with string argument.
On Mon, Mar 17, 2014 at 5:06 PM, Terry Reedy 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. 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 -- https://mail.python.org/mailman/listinfo/python-list
Re: 'complex' function with string argument.
On 3/17/2014 1:55 PM, Mark Dickinson wrote: Jayanth Koushik 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 -- https://mail.python.org/mailman/listinfo/python-list
Re: 'complex' function with string argument.
On Tue, Mar 18, 2014 at 6:22 AM, Marko Rauhamaa wrote: > Chris Angelico : > >> On Tue, Mar 18, 2014 at 5:15 AM, Marko Rauhamaa wrote: >>> Is "-2.0" a literal? >>> >>> What's the outcome of >>> >>>-2.0.__str__() >> >> If you mean (-2.0).__str__(), then it returns '-2.0', but that proves >> nothing. > > The point is, you don't need to "philosophize" about complex literals > when even negative numbers don't have literals in Python. Ah! I get you. The difference between literals and constants is one that almost never matters, though. Python may not have a syntax for negative or complex literals, but it does have notations for various sorts of constants, which function the same way. (Literals are by definition constants.) So Python may not have a convenient notation for "number of seconds in a week" (unless you work with DNS and find the bare integer 604800 convenient), but you can write 7*24*60*60 and it's just as good in a function: >>> ast.dump(ast.parse("7*24*60*60")) 'Module(body=[Expr(value=BinOp(left=BinOp(left=BinOp(left=Num(n=7), op=Mult(), right=Num(n=24)), op=Mult(), right=Num(n=60)), op=Mult(), right=Num(n=60)))])' >>> def f(x): return x + 7*24*60*60 >>> dis.dis(f) 2 0 LOAD_FAST0 (x) 3 LOAD_CONST 6 (604800) 6 BINARY_ADD 7 RETURN_VALUE There's absolutely no run-time cost to writing it out, and you get to be flexible with whitespace and such, which you can't do with literals. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: 'complex' function with string argument.
Chris Angelico : > On Tue, Mar 18, 2014 at 5:15 AM, Marko Rauhamaa wrote: >> Is "-2.0" a literal? >> >> What's the outcome of >> >>-2.0.__str__() > > If you mean (-2.0).__str__(), then it returns '-2.0', but that proves > nothing. The point is, you don't need to "philosophize" about complex literals when even negative numbers don't have literals in Python. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: 'complex' function with string argument.
On Tue, Mar 18, 2014 at 5:15 AM, Marko Rauhamaa wrote: >>> This '3 + 2j' is not a number, its an algebraic sum. >>> >>> This '3+2j' is a complex number. Ok, maybe not, but its closer to what >>> we expect (I'm sorry, but I like i instead of j ) >> >>Hmm. That's a pretty tricky distinction. > > Is "-2.0" a literal? > > What's the outcome of > >-2.0.__str__() If you mean (-2.0).__str__(), then it returns '-2.0', but that proves nothing. Lots of objects have a str() which isn't a literal. Closer to what you're talking about would be repr(), but even then, it doesn't prove that something's a literal. The easiest way to tell is probably ast.parse(): >>> ast.dump(ast.parse("-2.0")) 'Module(body=[Expr(value=UnaryOp(op=USub(), operand=Num(n=2.0)))])' It's an expression consisting of unary minus and the float literal 2.0. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: 'complex' function with string argument.
On Mon, Mar 17, 2014 at 12:15 PM, Marko Rauhamaa wrote: > Is "-2.0" a literal? > > What's the outcome of > >-2.0.__str__() No. The compiler will try to optimize it into a single constant if it can, but it has to be done in accordance with the order of operations. In that example, the __str__ method is called before the unary - is applied, resulting in an error. -- https://mail.python.org/mailman/listinfo/python-list
Re: 'complex' function with string argument.
On 3/17/14 12:03 PM, Chris Angelico wrote: ast.dump(ast.parse("complex( 3 +2j )")) "Module(body=[Expr(value=Call(func=Name(id='complex', ctx=Load()), args=[BinOp(left=Num(n=3), op=Add(), right=Num(n=2j))], keywords=[], starargs=None, kwargs=None))])" The sole argument to complex() is an expression which sums the integer 3 and the imaginary 2j, which results in the complex (3+2j), which complex() looks at and returns unchanged. And that's what you see. ~very nice. Ok, going along with Mark's comment about this bug report: See http://bugs.python.org/issue9574 This string '3 +2j' should probably be ok from the complex() string constructor standpoint, right? I mean, there might be more than one constructor for string, mighten-it? marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: 'complex' function with string argument.
Chris Angelico : > On Tue, Mar 18, 2014 at 3:18 AM, Mark H Harris wrote: >> Philosophically, I tend to think about it this way. A complex number >> is like any other number. I would not form a PI string like this> ' 3 >> .14 1 5 9265 3 . . .' I would rather see it formed like so, >> '3.1415926535' > > Right. Well, Java 7 allows you to embed underscores freely in numeric literals. Would be a nice addition to Python as well: if unit == 'G': count *= 1_000_000_000 vs: if unit == 'G': count *= 10 >> This '3 + 2j' is not a number, its an algebraic sum. >> >> This '3+2j' is a complex number. Ok, maybe not, but its closer to what >> we expect (I'm sorry, but I like i instead of j ) > >Hmm. That's a pretty tricky distinction. Is "-2.0" a literal? What's the outcome of -2.0.__str__() Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: 'complex' function with string argument.
Jayanth Koushik 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 -- https://mail.python.org/mailman/listinfo/python-list
Re: 'complex' function with string argument.
On Tue, Mar 18, 2014 at 3:18 AM, Mark H Harris wrote: > You actually answered your own question, as you were asking it. If the doc > says "whatever you do, don't push the purple button," well, leave the purple > button alone. :) (I don't know, push it if you want) https://www.wizards.com/magic/magazine/article.aspx?x=mtg/daily/mm/69 > If you monitor the PEP process, or have ever taken part in python-ideas, or > python-dev (either directly, or just lurking) you will notice that python is > developed through a very interesting active committee process (that is > really something phenomenal; cool community). Not really a committee, more of a champion-and-bikeshedders approach - often with more than one level of champion, as when a PEP has an author (the first champion) and either the BDFL or his delegate (the second champion, whose role is usually just to say yay or nay). It's a curious process, but one that works fairly well. > How should one spell a complex number? Should we use i or j ? Should the > imaginary part be set off somehow? Should literals be parsed differently > (or consistently) with correctly formed strings? Who knows, beats me. > > consider: complex( 3 + 2 j) > SyntaxError: invalid syntax complex( 3 +2j ) > (3+2j) > I don't know... you tell me. That's for the sake of parsing clarity. (Incidentally, the call to complex() is redundant in each case.) Everything in Python consists of tokens - those tokens, in your examples, are: "complex", "(", whitespace, "3", whitespace, "+", whitespace, "2", whitespace, "j", ")", end of line and "complex", "(", whitespace, "3", whitespace, "+", "2j", whitespace, ")", end of line In the first case, the parser then has two symbol-type tokens ("2" and "j") separated by whitespace, with no operator. That's a problem. Did you mean "2+j", or "2==j", etc? Since j is perfectly natural as a name, it's going to be interpreted that way. In the second case, that translates into a perfectly valid parse tree, because "2j" is an imaginary literal. >>> ast.dump(ast.parse("complex( 3 +2j )")) "Module(body=[Expr(value=Call(func=Name(id='complex', ctx=Load()), args=[BinOp(left=Num(n=3), op=Add(), right=Num(n=2j))], keywords=[], starargs=None, kwargs=None))])" The sole argument to complex() is an expression which sums the integer 3 and the imaginary 2j, which results in the complex (3+2j), which complex() looks at and returns unchanged. And that's what you see. complex('3+2j') > (3+2j) complex('3 +2j') > Traceback (most recent call last): > File "", line 1, in > complex('3 +2j') > ValueError: complex() arg is a malformed string > > Again, beats me. I just don't know. And now what you're looking at is the construction of a complex from a string. Now, instead of going by the rules of the Python lexer, it goes by the rules of the complex constructor. You can't use extra spaces there. You could, of course, write your own function that parses whatever format you like (including the use of i instead of j), or you can use ast.literal_eval to parse a string based on Python's lexing, but with complex(str) you follow the rules of complex(str). > Philosophically, I tend to think about it this way. A complex number is like > any other number. I would not form a PI string like this> ' 3 .14 1 5 9265 3 > . . .' I would rather see it formed like so, '3.1415926535' Right. > This '3 + 2j' is not a number, its an algebraic sum. > > This '3+2j' is a complex number. Ok, maybe not, but its closer to what we > expect (I'm sorry, but I like i instead of j ) Hmm. That's a pretty tricky distinction. In Python source code, those two are identical, and they're both rendered as a sum. (Lexically. The CPython optimizer, and presumably other Pythons' optimizers, will notice at compile time that you're adding two literals, and store the sum. But as you see from the AST above, it's the sum of two values.) It's actually not possible, as far as I know, to truly represent a complex number; all you can do is represent the sum of a real part and an imaginary part. > Also, philosophically, C ignores white space; python does not. That's not really anything to do with it. The two languages' approaches to whitespace inside expressions are identical, save that Python will only allow newlines if the expression is "clearly unfinished", eg if it has unbalanced open parens. Horizontal whitespace is fine in both languages. (Of course, C doesn't even _have_ a complex literal notation, so the distinction is slightly moot.) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: 'complex' function with string argument.
On 3/15/14 11:26 AM, Jayanth Koushik wrote: This is a very interesting philosophical question, one which I am surprised no one has answered; although, I think the reason for that might be entirely obvious. You actually answered your own question, as you were asking it. If the doc says "whatever you do, don't push the purple button," well, leave the purple button alone. :) (I don't know, push it if you want) If you monitor the PEP process, or have ever taken part in python-ideas, or python-dev (either directly, or just lurking) you will notice that python is developed through a very interesting active committee process (that is really something phenomenal; cool community). How should one spell a complex number? Should we use i or j ? Should the imaginary part be set off somehow? Should literals be parsed differently (or consistently) with correctly formed strings? Who knows, beats me. consider: >>> complex( 3 + 2 j) SyntaxError: invalid syntax >>> complex( 3 +2j ) (3+2j) >>> I don't know... you tell me. >>> complex('3+2j') (3+2j) >>> complex('3 +2j') Traceback (most recent call last): File "", line 1, in complex('3 +2j') ValueError: complex() arg is a malformed string >>> Again, beats me. I just don't know. But I do know that the spelling book says, Do it this way: complex('3+2j'). Seems simple enough. Philosophically, I tend to think about it this way. A complex number is like any other number. I would not form a PI string like this> ' 3 .14 1 5 9265 3 . . .' I would rather see it formed like so, '3.1415926535' This '3 + 2j' is not a number, its an algebraic sum. This '3+2j' is a complex number. Ok, maybe not, but its closer to what we expect (I'm sorry, but I like i instead of j ) Also, philosophically, C ignores white space; python does not. I agree with this now; before I did not. White space is just as much a part of how interpretation occurs, within symbol processing/parsing. Some choices are arbitrary, some are community concurrence (PEPs), some are philosophical, and most are just convenient intuition. My Greek professor used to say, "there is no 'why' in Greek". Python is similar. Cheers -- https://mail.python.org/mailman/listinfo/python-list
'complex' function with string argument.
Hi everyone! 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." Why is this so? Why can't spaces be allowed everywhere and simply ignored? I went through the source and it did not seem like this was an internal requirement, so it seems like a design choice. Is there any reason why spaces in the middle would be a problem? Jayanth Koushik -- https://mail.python.org/mailman/listinfo/python-list