On Thu, 29 Dec 2016 07:53:28 -0800, alex.jakime...@gmail.com wrote: > Code: > say permutations(50).elems > > > Result (2015.12,2016.08): > 30414093201713378043612608166064768844377641568960512000000000000 > > Result (2016.09,2016.10,2016.11): > 1 > > Result (2016.12,HEAD): > Cowardly refusing to permutate more than 20 elements, tried 50 > in block <unit> at /tmp/dF_8CAjznv line 1 > > > > Why refuse when it is doable? > > > Bisectable says that the first change appeared in > https://github.com/rakudo/rakudo/commit/8a66833d9b8d05b89ea5c0069370a67ec7374b8c > (which is when the error message was introduced, as far as I can see) > but it started erroring out after > https://github.com/rakudo/rakudo/commit/ab3a59c393e620654b788d89eed818b13b7e92a1
FWIW, I'm fine with the limit. We can handle resulting permutations up to a list of 2432902008176640000 elements and you'd get blue in the face waiting for that to reify. I'm assuming the limit was added so we could work with native types only, so making it handle larger cases would either require deoptimization of common cases or implementation of big-I cases just for cases no one will realistically bother to fully reify. If all you want is the element count, there's a better way to obtain it; just use a factorial: say [*] 1..50
