Order of operations (was: PEP 238 - The // operator should truncate instead of floor)
2007/8/29, "Martin v. Löwis" <martin@v.loewis.de>:
Wow, that caught me:
I'm not talking about division here, just the fact that in the first case, it was (-3) / 2 and not -(3/2). It's a surprise to me, taking into account that
Here, the behavior is always the same: -(3**2). Do you know why? Thanks! -- . Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/
Do you know why? Thanks!
It's a matter of precedence: ** has higher precedence than unary + and -, which has higher precedence than / and *, which have higher precedence than binary + and -. See power, factor, term in Grammar/Grammar. I'm not sure why precedence was defined that way, though. Regards, Martin
>>> Do you know why? Thanks! >> >> I'm not sure why precedence was defined that >> way, though. Scott> Because it is consistent with C's precedence rules. True enough, however Python doesn't support negative numbers as individual tokens at the lexical analysis level. -3.41 is '-' followed by '3.41'. In C it's a single token resolved at compile time. In the not-too-distant past negative numeric constants were tried, but that caused some other grief. I can't remember what. Skip
That is not true. ISO C99 defines (6.4.4.1) integer-constant: decimal-constant integer-suffix-opt octal-constant integer-suffix-opt hexadecimal-constant integer-suffix-opt decimal-constant: nonzero-digit decimal-constant digit and then (6.5.3) unary-expr: postfix-expr ++ unary-expr -- unary-expr unary-operator cast-expr sizeof unary-expr sizeof ( type-name ) unary-operator: one of & * + - ~ ! So -3.41 is definitely two tokens in C. Regards, Martin
On 8/29/07, Dirkjan Ochtman <dirkjan@ochtman.nl> wrote:
No, that would have been really bad. Anyone who's had high school algebra expects -x**2 to be -(x**2) and not (-x)**2. I think the weirdness comes from parsing -a/b as (-a)/b rather than -(a/b). It should be the latter, if compatibility with math notation is more important than compatibility with C. Oh well. Maybe in Python 4. :) -j
Jason Orendorff wrote:
I think the weirdness comes from parsing -a/b as (-a)/b rather than -(a/b).
This will sort of be fixed in 3.0, at least for /, because it will always mean float division, for which -(a/b) == (-a)/b. You'll have to use // to get weirdness, then. :-) -- Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | Carpe post meridiem! | Christchurch, New Zealand | (I'm not a morning person.) | greg.ewing@canterbury.ac.nz +--------------------------------------+
Do you know why? Thanks!
It's a matter of precedence: ** has higher precedence than unary + and -, which has higher precedence than / and *, which have higher precedence than binary + and -. See power, factor, term in Grammar/Grammar. I'm not sure why precedence was defined that way, though. Regards, Martin
>>> Do you know why? Thanks! >> >> I'm not sure why precedence was defined that >> way, though. Scott> Because it is consistent with C's precedence rules. True enough, however Python doesn't support negative numbers as individual tokens at the lexical analysis level. -3.41 is '-' followed by '3.41'. In C it's a single token resolved at compile time. In the not-too-distant past negative numeric constants were tried, but that caused some other grief. I can't remember what. Skip
That is not true. ISO C99 defines (6.4.4.1) integer-constant: decimal-constant integer-suffix-opt octal-constant integer-suffix-opt hexadecimal-constant integer-suffix-opt decimal-constant: nonzero-digit decimal-constant digit and then (6.5.3) unary-expr: postfix-expr ++ unary-expr -- unary-expr unary-operator cast-expr sizeof unary-expr sizeof ( type-name ) unary-operator: one of & * + - ~ ! So -3.41 is definitely two tokens in C. Regards, Martin
Alexandre Vassalotti wrote:
C doesn't have an exponentiation operator. You use the pow() function, instead:
Wouldn't it make more sense, then, to have unary +/- have higher precedence than the ** operator, so that -3**2 == 9? Regards, Dirkjan
On 8/29/07, Dirkjan Ochtman <dirkjan@ochtman.nl> wrote:
No, that would have been really bad. Anyone who's had high school algebra expects -x**2 to be -(x**2) and not (-x)**2. I think the weirdness comes from parsing -a/b as (-a)/b rather than -(a/b). It should be the latter, if compatibility with math notation is more important than compatibility with C. Oh well. Maybe in Python 4. :) -j
Jason Orendorff wrote:
I think the weirdness comes from parsing -a/b as (-a)/b rather than -(a/b).
This will sort of be fixed in 3.0, at least for /, because it will always mean float division, for which -(a/b) == (-a)/b. You'll have to use // to get weirdness, then. :-) -- Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | Carpe post meridiem! | Christchurch, New Zealand | (I'm not a morning person.) | greg.ewing@canterbury.ac.nz +--------------------------------------+
participants (8)
-
"Martin v. Löwis" -
Alexandre Vassalotti -
Dirkjan Ochtman -
Facundo Batista -
Greg Ewing -
Jason Orendorff -
Scott Dial -
skip＠pobox.com