ooopsy! I was sidetracked by totally misunderstood a previous comment thinking that these are whole-number divisions(=right shifts) like dividing by 10. Anyway, in this case the solution is to substitute Math::BigInt with Math::BigFloat in my previous post. Then you get the right result. BTW in Linux the command bc does arbitrary precision arithmetic and can be used to verify these numbers.

But why not use Math::GMPz as syphilis suggested and given that unexplained, to me, loop-incrementing bug.

bw, bliako

> BTW in Linux the command bc does arbitrary precision arithmetic and can be used to verify these numbers.

That was what I used. :) Further, the whole point of the script I was writing that led to this question was the desire to automate a process where I used bc, and then processed the output further. The (now-completed) perl script does everything in one step.

great you cracked it and are now able to sit back while the computer does all the work for you! There is Really *NOT* Another Way about that (sitting back and looking at the sweating computer I mean)

use strict;
use warnings;

use Math::BigInt;
use Digest::SHA qw(sha256_hex);

for(my $i=1;$i<=10;$i++){
    # the sha as a hex string (no '0x' prepended)
    my $hexstr = sha256_hex($i);

    # to create a bigint from a hex string we need to prepend '0x' to 
+it
    my $digest = Math::BigInt->new('0x'.$hexstr);

    # operate
    print "$i $digest\n";
    $digest /= 64;
    print "$i $digest\n";
}
[download]

1 48635463943209834798109814161294753926839975257569795305637098542720
+658922315
1 75992912411265366872046584627023053010687461339952805165057966473001
+0295661
2 96094161643976066833367867971426158458230048495430276217795328666133
+331159861
2 15014712756871260442713729370535337259098445077410980659030520104083
+33299372
3 35293215426786447154857697798367884701614677727176325092965345248689
+205321678
3 55145649104353823679465152809949819846272933948713007957758351951076
+8833151
4 33984360982413536682390860969296307922929415152052354251133793603654
+468157322
4 53100564035021151066235720264525481129577211175081803517396552505710
+1064958
5 10818240655469999731486825095773005325907358940236581977057259273658
+4172823453
5 16903501024171874580448164212145320821730248344119659339151967615091
+27700366
6 10492023800686533720501340709024820017001830686534338836405100876796
+5015414403
6 16393787188572708938283344857851281276565360447709904431882970119994
+53365850
7 54734117258892461880478870895348100103198302433611928089023761078319
+507514449
7 85522058217019471688248235773981406411247347552518637639099626684874
+2304913
8 20075373234943686845167158285967784892467090849631486320124245130906
+619831459
8 31367770679599510695573684821824663894479829452549197375194133017041
+5934866
9 11463511883541201508393500803711559652562721115888819482889049505863
+143503287
9 17911737318033127356864845005799311957129251743576280442014139852911
+1617238
10 3359281535163583886622750554468341756416232122807515421831543601247
+6449103317
[download]

Perhaps, misunderstanding began with

I think you need to set the precision to 1

which maybe stemmed from

p or precision ... 0 or 1 mean round to integer

which (i.e., Perl core module documentation) is wrong. "0" is "round to integer". "1" is not.

Allowing "accuracy" and "precision" for extended integers (through a pragma i.e. infecting everything which interacts with source code literals!) is, simply, very evil and can lead to bizarre infinite loops, as shown, but it's not a bug in itself, because documented (but should never be used (?))