Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Perl > Perl Misc > 50+ bits of arithmetic in a 32-bit bag

Reply
Thread Tools

50+ bits of arithmetic in a 32-bit bag

 
 
mailbox@cpacker.org
Guest
Posts: n/a
 
      08-09-2006
Our implementation of Perl under AIX
doesn't support 64-bit integer arithmetic;
so says "perl -V".

A search of these newsgroups turned up a
test of this fact as follows:

$two += 2;
$x = $two ** 63 + 25;
$y = $two ** 63 + 30;
if($x == $y) {print "64 bits not supported\n"}
else {print "64 bits supported\n"}

I found that it would give an affirmative
result if I used up to 55 instead of 63.
This suggests that a floating-point
format with a seven-byte fraction is
being invoked. Perhaps that's the native
floating-point of the AIX box?
At any rate, barring followups to the
contrary, I'll assume that I can treat
our Perl as having a 55-bit integer
arithmetic capability for accumulating
sums, at least. The code in question
doesn't have to be portable.

--
Charles Packer
mailboxATcpacker.org
http://cpacker.org/whatnews

 
Reply With Quote
 
 
 
 
xhoster@gmail.com
Guest
Posts: n/a
 
      08-09-2006
http://www.velocityreviews.com/forums/(E-Mail Removed) wrote:
> Our implementation of Perl under AIX
> doesn't support 64-bit integer arithmetic;
> so says "perl -V".
>
> A search of these newsgroups turned up a
> test of this fact as follows:
>
> $two += 2;
> $x = $two ** 63 + 25;
> $y = $two ** 63 + 30;
> if($x == $y) {print "64 bits not supported\n"}
> else {print "64 bits supported\n"}
>
> I found that it would give an affirmative
> result if I used up to 55 instead of 63.
> This suggests that a floating-point
> format with a seven-byte fraction is
> being invoked. Perhaps that's the native
> floating-point of the AIX box?
> At any rate, barring followups to the
> contrary, I'll assume that I can treat
> our Perl as having a 55-bit integer
> arithmetic capability for accumulating
> sums, at least.


That is a poor assumption. Just because the $x and $y are not identical
does not mean that they are what they are supposed to be.

On my machine, your test also passes for 55, but a more rigorous test
does not:

$ perl -le '$foo=55; print((2**$foo+30)-(2**$foo+25))'
8

I'm pretty sure that 5 != 8, so 55 bits is right out. On my machine, 52 is
high as I would go.

$ perl -le '$foo=52; foreach (1..1e7) { my $y =
((2**$foo+$_+1)-(2**$foo+$_));
die $_ unless $y == 1}'


Xho

--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service $9.95/Month 30GB
 
Reply With Quote
 
 
 
 
mailbox@cpacker.org
Guest
Posts: n/a
 
      08-10-2006

(E-Mail Removed) wrote:
> On my machine, your test also passes for 55, but a more rigorous test
> does not:
>
> $ perl -le '$foo=55; print((2**$foo+30)-(2**$foo+25))'
> 8
>
> I'm pretty sure that 5 != 8, so 55 bits is right out. On my machine, 52 is
> high as I would go.
>
> $ perl -le '$foo=52; foreach (1..1e7) { my $y =
> ((2**$foo+$_+1)-(2**$foo+$_));
> die $_ unless $y == 1}'



Thanks for that improvement! It behaves the same on our machine as on
yours. Fortunately, 52 bits is still plenty of magnitude for our
purposes.

--
Charles Packer
mailboxATcpacker.org
http://cpacker.org/whatnews

 
Reply With Quote
 
anno4000@radom.zrz.tu-berlin.de
Guest
Posts: n/a
 
      08-10-2006
<(E-Mail Removed)> wrote in comp.lang.perl.misc:
> (E-Mail Removed) wrote:
> > Our implementation of Perl under AIX
> > doesn't support 64-bit integer arithmetic;
> > so says "perl -V".
> >
> > A search of these newsgroups turned up a
> > test of this fact as follows:
> >
> > $two += 2;
> > $x = $two ** 63 + 25;
> > $y = $two ** 63 + 30;
> > if($x == $y) {print "64 bits not supported\n"}
> > else {print "64 bits supported\n"}
> >
> > I found that it would give an affirmative
> > result if I used up to 55 instead of 63.
> > This suggests that a floating-point
> > format with a seven-byte fraction is
> > being invoked. Perhaps that's the native
> > floating-point of the AIX box?
> > At any rate, barring followups to the
> > contrary, I'll assume that I can treat
> > our Perl as having a 55-bit integer
> > arithmetic capability for accumulating
> > sums, at least.

>
> That is a poor assumption. Just because the $x and $y are not identical
> does not mean that they are what they are supposed to be.
>
> On my machine, your test also passes for 55, but a more rigorous test
> does not:
>
> $ perl -le '$foo=55; print((2**$foo+30)-(2**$foo+25))'
> 8
>
> I'm pretty sure that 5 != 8, so 55 bits is right out. On my machine, 52 is
> high as I would go.
>
> $ perl -le '$foo=52; foreach (1..1e7) { my $y =
> ((2**$foo+$_+1)-(2**$foo+$_));
> die $_ unless $y == 1}'


That happens to coincide with the 53 bit mantissa in IEEE-something
floats. One bit is the sign bit, so 52 bits are safe.

Anno
 
Reply With Quote
 
Uri Guttman
Guest
Posts: n/a
 
      08-10-2006
>>>>> "m" == mailbox <(E-Mail Removed)> writes:

m> (E-Mail Removed) wrote:
>> On my machine, your test also passes for 55, but a more rigorous test
>> does not:
>>
>> $ perl -le '$foo=55; print((2**$foo+30)-(2**$foo+25))'
>> 8
>>
>> I'm pretty sure that 5 != 8, so 55 bits is right out. On my machine, 52 is
>> high as I would go.
>>
>> $ perl -le '$foo=52; foreach (1..1e7) { my $y =
>> ((2**$foo+$_+1)-(2**$foo+$_));
>> die $_ unless $y == 1}'



m> Thanks for that improvement! It behaves the same on our machine as on
m> yours. Fortunately, 52 bits is still plenty of magnitude for our
m> purposes.

it would be hard to use a cpu today that doesn't use ieee float formats
(any perl vax users around? . so that mantissa size for double floats
(64 bits) will be the same for almost any common box today.

and this one liner also shows the transition from integers to float:

perl -le "print '2**', \$_, ': ', 2**\$_, ' - 1 = ', 2**\$_ - 1 for 47 .. 52"

notice that the -1 stops working after 49 bits so that is the largest
integer you can store in a double. note that this is a decimal issue so
even if the mantissa is 53 bits, you can't operate with a 1 (decimal)
because it takes 4 bits to hold a decimal digit. this is why this shows
49 usable (in decimal) integer bits but the ieee format has 53 bits in
the mantissa.

uri

--
Uri Guttman ------ (E-Mail Removed) -------- http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
 
Reply With Quote
 
Ilya Zakharevich
Guest
Posts: n/a
 
      08-10-2006
[A complimentary Cc of this posting was sent to
Uri Guttman
<(E-Mail Removed)>], who wrote in article <(E-Mail Removed)>:
> perl -le "print '2**', \$_, ': ', 2**\$_, ' - 1 = ', 2**\$_ - 1 for 47 .. 52"


Converting to version which has a better chance to work in the shells' maze:

perl -le 'print q(2**), $_, q(: ), 2**$_, q( - 1 = ), 2**$_ - 1 for 47 .. 52'
2**47: 140737488355328 - 1 = 140737488355327
2**48: 281474976710656 - 1 = 281474976710655
2**49: 562949953421312 - 1 = 562949953421311
2**50: 1.12589990684262e+15 - 1 = 1.12589990684262e+15
2**51: 2.25179981368525e+15 - 1 = 2.25179981368525e+15
2**52: 4.5035996273705e+15 - 1 = 4.5035996273705e+15

> notice that the -1 stops working after 49 bits so that is the largest
> integer you can store in a double.


Nope. 53 bits is OK.

> note that this is a decimal issue so even if the mantissa is 53
> bits, you can't operate with a 1 (decimal) because it takes 4 bits
> to hold a decimal digit.


Nope, this is just a buggy Perl's convertion to string.

perl -le 'print q(2**), $_, q(: ), sprintf(q(%.0f), 2**$_), q( - 1 = ), sprintf(q(%.f), 2**$_ - 1) for 47 .. 55'
2**47: 140737488355328 - 1 = 140737488355327
2**48: 281474976710656 - 1 = 281474976710655
2**49: 562949953421312 - 1 = 562949953421311
2**50: 1125899906842624 - 1 = 1125899906842623
2**51: 2251799813685248 - 1 = 2251799813685247
2**52: 4503599627370496 - 1 = 4503599627370495
2**53: 9007199254740992 - 1 = 9007199254740991
2**54: 18014398509481984 - 1 = 18014398509481984
2**55: 36028797018963968 - 1 = 36028797018963968

Hope this helps,
Ilya
 
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
Design problem related to A-Bag-Of-Fruit is not the same as A-Bag-Of-Apple T.A. C++ 7 12-03-2006 04:29 PM
Usual Arithmetic Conversions-arithmetic expressions joshc C Programming 5 03-31-2005 02:23 AM
8 bits/ch vs 16 bits/ch in PS Terry Digital Photography 5 01-21-2004 06:59 PM
8-Bits vs 12 or 16 bits/pixel; When does more than 8 bits count ? Al Dykes Digital Photography 3 12-29-2003 07:08 PM
win XP 32 bits on a 64 bits processor.. Abbyss Computer Support 3 11-13-2003 12:39 AM



Advertisments