The code presented in the article doesn't communicate the problem. It communicates a clever optimization that will break if the spec changes at all.
This code should be readable enough to give you an idea what is happening and how to change it.
my $board-depth = 8;
my $board-width = 8;
my $squares = $board-depth * $board-width;
my @grains-per-square = ( 1 .. $squares ).map({ 2 ** ($_-1) })
say [+] @grains-per-square;
Which if you read Perl6 says number of squares, and in each one put 2^n-1 grains, then add them all up.
Hint: `[]` is the reduction metaoperator, it lets you specify an operator to use when reducing a list. [+] means "add it up".
It finishes basically instantly, and while Perl6 has gotten a lot faster, it is not a fast language (yet?). So no need to optimize this.
I mean you write the code and then marketing will have a poorly specified variation like "double only the odd ones".
If you implemented this as `2^64-1` then you are starting from scratch.
For the above the map only needs a tweak:
map({ $_ %% 2 ?? $_ :: 2**(n-1) })
Or whatever it turns out that marketing meant.
In the article, I didn't see informational intentionality, I saw premature optimization and obfuscation.