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, Comp
On 8/29/07, Dirkjan Ochtman <[EMAIL PROTECTED]> wrote:
> 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?
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
__
Martin v. Löwis wrote:
> Alexandre Vassalotti schrieb:
>> C doesn't have an exponentiation operator. You use the pow() function,
>> instead:
>
> Right. Then Scott's claim ("Because it is consistent with C's precedence
> rules.") can't be true - from C precedence, it does not follow that **
> must
On 8/29/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Scott Dial schrieb:
> > Martin v. Löwis wrote:
> >>> Do you know why? Thanks!
> >> I'm not sure why precedence was defined that
> >> way, though.
> >>
> >
> > Because it is consistent with C's precedence rules.
>
> Maybe I'm missing somethi
> 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.
That is not true. ISO C99 defines (6.4.4.1)
integer-constant:
Scott Dial schrieb:
> Martin v. Löwis wrote:
>>> Do you know why? Thanks!
>> I'm not sure why precedence was defined that
>> way, though.
>>
>
> Because it is consistent with C's precedence rules.
Maybe I'm missing something - how exactly is the exponentiation
operator spelled in C?
Regards,
Mar
>>> 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
Martin v. Löwis wrote:
>> Do you know why? Thanks!
>
> I'm not sure why precedence was defined that
> way, though.
>
Because it is consistent with C's precedence rules.
-Scott
--
Scott Dial
[EMAIL PROTECTED]
[EMAIL PROTECTED]
___
Python-Dev mailing
> 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.
R
2007/8/29, "Martin v. Löwis" <[EMAIL PROTECTED]>:
> It would have been good if you had indicated what result you had
> expected instead. I assume 0; to get 0, you have to write -(3/2)+3/2,
> or 0-3/2+3/2.
Wow, that caught me:
>>> -3/2+3/2
-1
>>> 0-3/2+3/2
0
>>>
I'm not talking about division he
11 matches
Mail list logo
