clementgallet / fivestage444 Goto Github PK

((cube2.get_dist_edgcen() - (distEdgCen%3) + 4) % 3 ) + distEdgCen - 1; // TODO: Could make a better formula...
return (prune_table_edgcen[idx>>2] >> ((idx & 0x3) << 1)) & 0x3;

As lookup table is always faster than "%" operations,
the first line can be replaced by:
int[][] GetPrun = new int[MAXDEPTH][3]
GetPrun[currentdist][get_dist()];
the second line can be replaced by:
return UPack[prune_table_edgecen[idx>>2]][idx&0x3];
int[][] UPack = new int[256][4], whilch UPack[i][j] = i >> ((j & 0x3) << 1)) & 0x3 // for 4 entrance in one byte, and it can contains 5 entrance in one byte as 3^5 < 2^8, as Kociemba's Cube Explorer and my 4x4x4 solver(edge12.java) did.

Instead of always applying the whole sequences to the cube, we could store one cube per move and start from the last position where the sequences are identical. This needs some storing and a lot of array copying though.

In particular, if I hack Tools.randomCube to set int scramble_len = 0;, cg.fivestage.Main just hangs.

Stage 2 is currently slow because the center coordinate is too big (51,482,970) to use one move table. So it is split into two numbers representing F and B centers respectively, both using the same move table. However, splitting and merging take a lot of computation.
One solution would be to keep two numbers all the way, but this storing is redundant (10,626_10,626 = 112,911,876), so the total number of coordinates with this system is 10,626_10,626*420 = 47,422,987,920 for 21,622,847,400 real positions. With symmetry reduction (8), the pruning table would have a size of at least 1,186 MB !

It looks like it's doing 1000 random turns to a solved cube instead.