I don't think so...
First of all it depends of the definition of a move... if a method as the one you use ends by the center, it will have a very weaker move count in SSHTM than in OBHTM... )
Moreover reduction method isn't made in order to have a low move count but in order to be easy if we already know how to solve a 3x3x3...
I see. I never understood why a move such as
r was defined to be 2 moves, the outer right face and the inner right slice. That forces a single slice turn to require
3 moves, the outer block turn and inner block turn, then reversing the outer block turn. Peculiar.
If an outer face can move "all by itself" then an inner slice should have the same capability.
I can see how reduction turns the 4x4x4 into a 3x3x3 for ease of learning. But what happens if you remembered the center layout incorrectly?
Oops, you get to resolve at least 8 centers.
I always do the corners first on the 4x4x4; it tells me what centers must go where. I am searching for better edge-pairing algorithms to reduce the movecount for that phase. My last layer solving is optimized now that I learned all of the algs. That leaves me a "ring" around the cube. I am having my program solve as many of these as possible. Currently it has
every 4-turn, 5-turn, 6-turn, and 7-turn solution mapped. It can also probe these positions in RAM during the search, so that an 8-move search really is capable of seeing up to 15 moves into the future. Once it hits any such pre-computed position, the solution is applied, and the cube is solved.
I am solving the 8-turn center database right now, but it will take a while to finish. The reason is, I solve each distance from each of the 24 possible rotated states. So I have 24 times as many positions, but the lookup speed is incredibly fast.
I have enough RAM to solve the 9- and 10-turn center databases. I'm not sure what the longest "centers-unsolved-only" position is, but it will be cool if my program will be able to go instantly from the last-layer to the solved state
