rokicki
commented
5 months ago Fixed in commit 5b6da366d3faf7e02c1ae6f4d7d73757e2036228. I switched from 32-bit to 64-bit numbers (although even 64-bit may overflow, so I'll have to figure out what to do there). I also changed the computation to use the cycle counts of the permutation rather than iterate.
This may actually give different results in puzzles that have identical pieces, but if there are identical pieces this new computation is more "accurate" since the order is a move thing and should be independent of the "start" position.
Thanks for the report.
Using the file samples/main/6x6x6obtm.tws, I want to get the order of the scramble "L' r D2 r u l B2 3r2 D' D2 d' U' 3r' r L' 3f' b F' 3d' R2 B2 3r' 3u R' l' U' 3b2 r2 3b L' 3d2 3f' l' 3d2 L' 3d2 D' D' u2 F2 D2 3u' l 3r' F' F2 l2 u' d f'".
If I run the order separately for each set I get instant outputs. CENTER: 38 CENTER2: 234 CENTER3: 240 CENTER4: 68 EDGE: 462 EDGE2: 23 CORNER: 7 lcm(38, 234, 240, 68, 462, 23, 7) = 5354228880
If I run the order normally, I get the output 1059261584 (overflow, 5354228880 - 2^32) in 11 minutes.
For the overflowing problem I suggest using ull to store orders, and for the speed problem I suggest calculating the orders of each set and computing their lcm.