470,619 Members | 2,033 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 470,619 developers. It's quick & easy.

Perl Math Question


An odd (to me) behavior I was hoping someone could explain.

Take the simple command:

perl -e 'print 0xCEC5 + 0xFFFFE253 & 0xFFFF'

I tried this on a number of computers. Most give 0xFFFF, which just
seems wrong. This includes Perl 5.6 and 5.8 on Linux and Darwin (OSX).
Also one Solaris box with 5.0. One computer (Perl 5.6, HPUX) gave what
I thought to be the correct answer (0xB118). Is this some sort of type
conversion issue that trips up the 32-bit PowerPCs and x86s but the
64-bit HPUX avoids?

Interestingly,

perl -e 'print 0xCEC5 + 0xFFFFE253 & 0xBEEF'

0xBEEF

Neat trick. Totally wrong answer, though.

perl -e 'print (0xCEC5 + 0xFFFFE253) & 0xFFFF'

gives 0x10000B118, which I don't understand.

perl -e 'print 0xCEC5 + (0xFFFFE253 & 0xFFFF)'

gives 0x1B118, which makes sense.

Obviously, I'm not grokking the perl bitwise-and (&) operator. The FAQ
warned about accidently anding strings, but stuff like

print oct("0xCEC5") + oct("0xFFFFE253") & oct("0xFFFF")

also gets the wrong answer, so I don't think that's my problem.

Any enlightenment appreciated.

CP

--
'When religion and politics ride in the same cart, the whirlwind follows.'
Jul 19 '05 #1
3 5459
Chris Pruett <sp**@pruett.org> wrote in message news:<150920032356168229%sp**@pruett.org>...
<snip> perl -e 'print (0xCEC5 + 0xFFFFE253) & 0xFFFF'

gives 0x10000B118, which I don't understand.

<snip>

This is hexadecimal arithmetic (not maths ;-> ) and the answer is
correct.

Simply add 0xCEC5 to 0xFFFFE253 and the result is 0x10000B118.

Anding 0xFFFF with 0x10000B118, leaves the least significant four
digits alone
i.e. in binary, bitwise anding 1010 with 1111 and you get 1010.

Perl does not appear to left fill 0xFFFF with leading zeroes so you do
not lose the five most significant digits of the addition result. I
would hesitate to say that perl is left filling with 1's on an and
operation; rather that it performs the bitwise operation on as many
bits as are appropriate; in this example the least significant four.

HTH

Lesley
Jul 19 '05 #2
> >perl -e 'print (0xCEC5 + 0xFFFFE253) & 0xFFFF'
gives 0x10000B118, which I don't understand.

This is hexadecimal arithmetic (not maths ;-> ) and the answer is
correct.


However, perl -we will give a warning, which may help the understanding.
The &0xFFFF is applied to the return value of the print.
Jul 19 '05 #3
In article <3F***************@world.std.com>, Bill N1VUX
<wd*@world.std.com> wrote:
perl -e 'print (0xCEC5 + 0xFFFFE253) & 0xFFFF'
gives 0x10000B118, which I don't understand.

This is hexadecimal arithmetic (not maths ;-> ) and the answer is
correct.


However, perl -we will give a warning, which may help the understanding.
The &0xFFFF is applied to the return value of the print.


Thanks for the reply.

Interesting point about the return value of the print. That seems to
explain how I get 0x10000B118 from

perl -e 'print (0xCEC5 + 0xFFFFE253) & 0xFFFF'

I'm still on my quest to get the right answer though (0xB118).

$x = (0xCEC5 + 0xFFFFE253);
print "$x\n";
$x &= 0xFFFF;
print "$x\n"'

4295012632 [0x10000B118]
65535 [0xFFFF]

That's still not the answer I expect.

In the $x &= 0xFFFF, does Perl try to convert the 0x10000B118 to a
native integer type (32-bit), detect the overflow, and saturate the
result (0xFFFFFFFF) before applying the bitwise-and? That would seem
to explain some of the results I'm getting and it might explain why
the 64-bit HPUX version gets the correct number.
CP

--
'When religion and politics ride in the same cart, the whirlwind follows.'
Jul 19 '05 #4

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

58 posts views Thread by @ | last post: by
2 posts views Thread by TSO | last post: by
6 posts views Thread by WipeOut | last post: by
20 posts views Thread by Xah Lee | last post: by
reply views Thread by Xah Lee | last post: by
reply views Thread by Kirt Loki Dankmyer | last post: by
13 posts views Thread by squash | last post: by
3 posts views Thread by haochen89 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.