6

I am trying to obtain the umptieth element of an array:

my @lazy-array = lazy 1, 11, 121 ... 10**100;
say @lazy-array[10**50];

This yields

Cannot unbox 167 bit wide bigint into native integer

Same problem if I assign it to a variable. This does not seem to be reflected in the documentation, and wonder if it's a feature or a bug. Also, what would be the correct way of acessing those positions (other than iterating)

jjmerelo
  • 22,578
  • 8
  • 40
  • 86
  • 3
    "Array subscripts use native ints; that's why you get the error ... you might ... define a new BigArray that uses Ints as array subscripts." -- [jjmerelo, 2019, answer to **Cannot unbox 65536 bit wide bigint into native integer**](https://stackoverflow.com/a/54529118/1077672) ;) See the section **Limits to allocations and indexing of the default array type** in my answer to the same question for some related discussion including the then current Rakudo/NQP/MoarVM implementation limits. – raiph Apr 04 '20 at 19:39
  • @raiph aw, man... I should have baked it in the documentation back then. – jjmerelo Apr 05 '20 at 07:32
  • 1
    (I've translated what you say to "I [could and would] have baked it in the doc [if I'd thought to do so, and think I will now]".) But it's [an esoteric implementation limit](https://stackoverflow.com/questions/61031107/do-array-indices-need-to-be-native-ints?noredirect=1#comment107979938_61031617). Imo a "cure" (mentioning it in official doc) will likely be worse than the disease. I see scope for there being a **Sparse Array** page, but presume it will inevitably attract implementation specific details such as performance commentary including benchmarks, so it feels premature to me in 2020. – raiph Apr 05 '20 at 10:17
  • 1
    (When "should" official doc mention implementation limits? Afaik there's a presumption in raku doc that if some write operation stores `42`, then a read of the same location returns `42`. This isn't guaranteed, and the likelihood of failure varies depending on (hardware) implementation (eg [Chipkill](https://en.wikipedia.org/wiki/Chipkill)). But I don't recall the official doc of any programming language ever mentioning this, and I think that's a good thing. In this case we're considering software limits, not hardware limits, but it's still an issue of documenting the ideal vs implementation.) – raiph Apr 05 '20 at 10:55

1 Answers1

7

In the current implementation in Raku, which is based on NQP, array indexes have a maximum of 63 bits (at least on 64bit builds).

use nqp;
my $l := nqp::list;
dd nqp::atpos($l,0x7fff_ffff_ffff_ffff);  # Mu
dd nqp::atpos($l,0x7fff_ffff_ffff_ffff + 1);
# Cannot unbox 64 bit wide bigint into native integer

I would not consider it a feature or a bug, but a limitation of the current implementation.

Please note that you could use Array::Sparse if you want to use larger indexes.

Elizabeth Mattijsen
  • 25,654
  • 3
  • 75
  • 105
  • 7
    Given that even if you had a `int1` array you'd *still* need over an exabyte of storage to address with anything beyond a 64-bit integer, I'm not sure this is a limitation we'll practically run into any time soon. :-) – Jonathan Worthington Apr 04 '20 at 22:13