Yes, I have position<->index so in theory this would be possible. An intermediate array would be a necessary condition for this algorithm to be efficient, and you have two: one for the last iteration (read) and one for the current iteration (write). So the memory requirement would be 15 + 2 x 7.5 = 30 GB, which would not fit on my machine. I guess the read-array could be on disk, but this adds (buffered) I/O and you still need at least 15 + 7.5 = 22.5 GB, leaving less than 1.5 GB for OS, runtime environment, etc. Not sure this would fit either. Or you need to slice the database and work through the slices in a suitable order, just like regular databases.If you have position2index and vice versa on this array, you can simply start with the initial position and scan the array repeatedly. It would be handy if you also kept an intermediate bitarray of 7.5 Gb of all positions reached in the previous iteration. Then you can iterate over all 1-bits and compute successors of all positions reached in the last iteration and add those to the base array and the next queue. Essentially this is equal to the 2-bit algorithm for database generation, I think by Wu & Beal, but here you use repeated forward passes instead of retrograde computations. It does require indexing, but if you have already that infractructure in place, it should be similar to building regular databases
Anyway, I liked the simplicity of my approach, which also needs less memory (15 GB + node stack, say 100 MB). It doesn't need to scan for positions to process and build them from their index - simply continue with the current node in a flat loop. It is not necessary to keep track of the (max.) depth, this is just a fun fact. Still it would be interesting to know how many iterations your method would take, i.e., what is the minimum depth to reach all positions?
