# Operator precedence of exponentiation (**) and complement (~)

Discussion in 'Ruby' started by Andrew Savige, Mar 26, 2009.

1. ### Andrew SavigeGuest

The operator precedence table at:=0A=0A http://phrogz.net/ProgrammingRuby/l=
anguage.html#table_18.4=0A=0Astates that the exponentiation operator (**) h=
as higher precedence than=0Athe complement operator (~). Ditto for operator=
precedence in Python.=0A=0AYet the following program:=0A=0A x =3D ~2**3=0A=
print x, "\n" # prints -27 in Ruby; prints -9 in Python=0A=0Asurprise=
d me by printing -27 (I am using ruby 1.8.6).=0A=0ABTW, the following progr=
am prints -9 in both Ruby and Python:=0A=0A x =3D ~(2**3)=0A print x, "\n"=
=0A=0AIs this a Ruby bug?=0A=0AThanks,=0A/-\=0A=0A=0A The new Internet=
Explorer 8 optimised for Yahoo!7: Faster, Safer, Easier.

Andrew Savige, Mar 26, 2009

2. ### Heesob ParkGuest

2009/3/26 Andrew Savige <>:
>
> The operator precedence table at:
>
> =C2=A0http://phrogz.net/ProgrammingRuby/language.html#table_18.4
>
> states that the exponentiation operator (**) has higher precedence than
> the complement operator (~). Ditto for operator precedence in Python.
>
> Yet the following program:
>
> =C2=A0x =3D ~2**3
> =C2=A0print x, "\n" =C2=A0 =C2=A0 =C2=A0# prints -27 in Ruby; prints -9 i=

n Python
>
> surprised me by printing -27 (I am using ruby 1.8.6).
>
> BTW, the following program prints -9 in both Ruby and Python:
>
> =C2=A0x =3D ~(2**3)
> =C2=A0print x, "\n"
>
> Is this a Ruby bug?
>

According to the japanese reference
manual(http://doc.loveruby.net/refm/api/view/spec/operator),
this is not a bug.
I guess this precedence change was made on ruby 1.8.0

C:\work\ruby168\bin>ruby -v -e 'p ~2**3'
ruby 1.6.8 (2002-12-24) [i586-mswin32]
-9

C:\work\ruby180\bin>ruby -v -e 'p ~2**3'
ruby 1.8.0 (2003-08-04) [i386-mswin32]
-27

Regards,

Park Heesob

Heesob Park, Mar 26, 2009

3. ### Andrew SavigeGuest

Heesob Park wrote:=0A> According to the japanese reference=0A> manual(http:=
//doc.loveruby.net/refm/api/view/spec/operator),=0A> this is not a bug.=0A>=
I guess this precedence change was made on ruby 1.8.0=0A>=0A> C:\work\ruby=
168\bin>ruby -v -e 'p ~2**3'=0A> ruby 1.6.8 (2002-12-24) [i586-mswin32]=0A>=
-9=0A>=0A> C:\work\ruby180\bin>ruby -v -e 'p ~2**3'=0A> ruby 1.8.0 (2003-0=
8-04) [i386-mswin32]=0A> -27=0A=0AThanks. Here's another one that surprised=
me. Running:=0A=0Ay =3D 5 % x =3D 3=0Aprint "x=3D", x, " y=3D", y, "\n"=0A=
=0Aproduces:=0A=0Ax=3D3 y=3D2=0A=0AThat is, it seems that:=0A=0Ay =3D 5 % x=
=3D 3=0A=0Ais being parsed as:=0A=0Ay =3D 5 % (x =3D 3)=0A=0Adespite the %=
operator having a higher precedence than the =3D operator.=0AI expected it=
to be parsed as:=0A=0Ay =3D (5 % x) =3D 3=0A=0Aproducing a syntax error.=
=0A=0AIf this is a deliberate feature, I'd be interested in learning more a=
bout it.=0AIf anyone knows a good reference on the Ruby parser, please let =
me know.=0A=0AThanks,=0A/-\=0A=0A=0A=0A Enjoy a safer web experience. =
Upgrade to the new Internet Explorer 8 optimised for Yahoo!7. Get it now.

Andrew Savige, Mar 26, 2009