Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Perl > Perl Math Question

Reply
Thread Tools

Perl Math Question

 
 
Chris Pruett
Guest
Posts: n/a
 
      09-16-2003

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 (0xB11. 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.'
 
Reply With Quote
 
 
 
 
Lesley
Guest
Posts: n/a
 
      09-17-2003
Chris Pruett <(E-Mail Removed)> wrote in message news:<150920032356168229%(E-Mail Removed)>...
><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
 
Reply With Quote
 
 
 
 
Bill N1VUX
Guest
Posts: n/a
 
      09-21-2003
> >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.
 
Reply With Quote
 
Chris Pruett
Guest
Posts: n/a
 
      09-23-2003
In article <(E-Mail Removed)>, Bill N1VUX
<(E-Mail Removed)> 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 (0xB11.

$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.'
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Math.random() and Math.round(Math.random()) and Math.floor(Math.random()*2) VK Javascript 15 05-02-2010 03:43 PM
Math.min and Math.max for byte / short Philipp Java 9 07-23-2008 12:37 AM
math.h trig functions questions (and some forgotten high school math) Mark Healey C Programming 7 05-22-2006 10:42 AM
Re: Is still math.h the C++ math library ? AciD_X C++ 4 04-01-2004 07:29 PM
Why can I not use: Math a=new Math(); chirs Java 18 03-02-2004 06:00 PM



Advertisments