Because the range operator (integer iterator) is not affected by bigint. You can also do:

use strict;
use warnings;
use bigint;

my $answer = 0;
for my $i ( map 0+$_,1 .. 999 ) {
  print "$i: $answer\n";
  $answer += $i ** $i;
}

$answer %= 10 ** 10;

print "$answer\n";
[download]

Because the range operator (integer iterator) is not affected by bigint

Is that intentional?

Is that intentional?

Yes. The range operator is intended to be efficient for the majority of every day use cases.

As you've already discovered, if you need to iterate infinite precision integers, you can easily use the c-style alternative.

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

>Is that intentional?

let's say it's historical. :)

I suppose the range iterator is just older than bigint.

I wouldn't be surprised if bigint is just just a hack to overload scalars with objects and the effect of iterating over a range was forgotten.

Cheers Rolf

I'll search and update a similar discussion we had about this.

UPDATE: here it is Infinity and Inf?

IMHO a bug or at least a reasonable feature request.

UPDATE:

A two part answer to your question:

Part1:

As I thought, the range operator only returns "normal" integers, and 145**145 causes an overflow and becomes INF.

But copying to another var helps.

my $answer = 1;
for my $j ( 1 .. 999 ) {
  print "$i: $answer\n";
  $i=$j+0;                 # $i is now bigint
  $answer += $i ** $i;
}
[download]

For the records, I didn't say brute force is the best way to solve an Euler question... ;)

Part2:

The second part of the answer is that foreach doesn't do a scalar assignment to $i, where bigint could intercept by auto-blessing $i into Math::BigInt. Foreach makes $i an alias of the integer values from the range, such that the **-operator isn't overloaded and produces an overflow.

So the only way to solve this is to make the range operator operating on big-ints on demand.

My off the cuff guess would be that the bigint pragma isn't affecting the iterator underlying your 1..999 (which I want to say is optimized under the covers so an actual list isn't built) whereas it does affect the explicit incrementing.

You can confirm that this issue is isolated to the range operator by first taking it out of the for loop and then throwing in a translation with map.

Problem still exists below, so it's not some optimization of the for loop:

my @a = (1..999);
for my $i (@a) {
[download]

Problem goes away due to using integers not created by the range operator:

my $j = 0;
my @a = map {++$j} (1..999);
for my $i (@a) {
[download]