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.
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.
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: 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.
On Wed, Mar 19, 2014 at 4:09 AM, Marko Rauhamaa ma...@pacujo.net 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.
Ian Kelly ian.g.ke...@gmail.com: On Wed, Mar 19, 2014 at 4:09 AM, Marko Rauhamaa ma...@pacujo.net 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 5:33 AM, Ian Kelly ian.g.ke...@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 -- 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 ian.g.ke...@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 -- 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 s...@pobox.com wrote: On Wed, Mar 19, 2014 at 5:33 AM, Ian Kelly ian.g.ke...@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). -- https://mail.python.org/mailman/listinfo/python-list
Re: 'complex' function with string argument.
On Wed, Mar 19, 2014 at 4:53 AM, Marko Rauhamaa ma...@pacujo.net wrote: Ian Kelly ian.g.ke...@gmail.com: On Wed, Mar 19, 2014 at 4:09 AM, Marko Rauhamaa ma...@pacujo.net 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.
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 6:04 PM, Christian Gollwitzer aurio...@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 -- 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.
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.
Christian Gollwitzer aurio...@gmx.de: 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.
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 pyshell#17, line 1, inmodule
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.
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 pyshell#17, line 1, in module
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
Re: 'complex' function with string argument.
On Tue, Mar 18, 2014 at 3:18 AM, Mark H Harris harrismh...@gmail.com 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 pyshell#17, line 1, in module
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.
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
--
https://mail.python.org/mailman/listinfo/python-list
Re: 'complex' function with string argument.
Chris Angelico ros...@gmail.com: On Tue, Mar 18, 2014 at 3:18 AM, Mark H Harris harrismh...@gmail.com 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.
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.
On Mon, Mar 17, 2014 at 12:15 PM, Marko Rauhamaa ma...@pacujo.net 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 Tue, Mar 18, 2014 at 5:15 AM, Marko Rauhamaa ma...@pacujo.net 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.
Chris Angelico ros...@gmail.com: On Tue, Mar 18, 2014 at 5:15 AM, Marko Rauhamaa ma...@pacujo.net 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 6:22 AM, Marko Rauhamaa ma...@pacujo.net wrote: Chris Angelico ros...@gmail.com: On Tue, Mar 18, 2014 at 5:15 AM, Marko Rauhamaa ma...@pacujo.net 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.
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
--
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 tjre...@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 -- 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 s...@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 -- 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 ros...@gmail.com wrote: On Tue, Mar 18, 2014 at 10:59 AM, Skip Montanaro s...@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 -- 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 ros...@gmail.com: On Tue, Mar 18, 2014 at 5:15 AM, Marko Rauhamaa ma...@pacujo.net 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) class 'complex' 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, 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
floatj
float+floatj
float-floatj
For the same reason that float(2) works, we should also allow strings
that look like:
float
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 pyshell#17, line 1, in module
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 Tue, Mar 18, 2014 at 3:52 PM, Steven D'Aprano st...@pearwood.info 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
