Transforming Algorithms?

blgentry

Veteran
Joined
Apr 10, 2008
Messages
263
Location
Miami, Florida
This probably belongs in a cube theory or cube "math" section or something, but this is the right place for now I hope.

I'm interested in transforming an algorithm into a different sequence of moves, but of course having the new algorithm perform the same task.

Specifically, I'm interested in doing this:

X is the algorithm.
Z is a very small sequence like R U .
Y is what we are solving for, such that:

Z Y Z' == The same effect as X

I've tried some simple experiments with my cube and it is not obvious to me how to do this, or if it is even possible.

The reason I want to do this is sort of odd: I'm trying to hide algorithms from the user of a computer program I am writing. I want to present setup sequences and have the user solve the alg/situation I am presenting, but to not have any prior idea of the alg/situation I am setting up. Like giving a setup for a T Permutation, but not using the standard setup for a T, so that the user won't know a T is being set up.

I have already employed a transformation method with cube rotations, and it works flawlessly, but some algs are still recognizable, even after being transformed, due to repeated sequences.

Any other suggestions for transforming an alg to a different sequence of moves would also be appreciated.

Thanks,

Brian.
 
Conjugate by superflip. :p

What tools are you using? You can always solve the conjugates with ACube or CE...
Otherwise, this might go under my dream of a 25-mover scramble generator for any state. Is it possible to hack a 2-phase solver to give 25-move solutions, preferably a few / choose the most chaotic one?

Also, are these mostly LL cases?

EDIT:
AHA!
Double-layer turn converter!
T-perm: l f u' r' f' r u2 f' l' u' f r u' r'
 
Last edited:
Conjugate by superflip. :p

:)

What tools are you using? You can always solve the conjugates with ACube or CE...

My current idea is to perform the calculations on the fly in the program. That's what I'm doing with my cube rotate transformations. They are extremely fast, as they are so simple to implement.

I suppose I could choose a set of things to do, and pre-compute a whole boatload of scrambles, labeling each with what they do, and then pick from them. I'd still rather do it on the fly, but I'm open to this if I can figure out how to do it with an external tool ahead of time. Playing with Cube Explorer, it is not obvious to me how to solve my proposed conjugates.

Otherwise, this might go under my dream of a 25-mover scramble generator for any state. Is it possible to hack a 2-phase solver to give 25-move solutions, preferably a few / choose the most chaotic one?

I have never delved into the math or techniques of computer based solvers, so this question, while seemingly a good one, is over my head at the moment.

Also, are these mostly LL cases?

100% Last Layer cases. In fact, the current version of my program is purely for PLLs. I may add OLL capability to it in the future.

A friend and I have collaborated on the idea, but worked separately on our on versions of this. His does all possible Last Layer cases by combining an OLL, a random AUF and a PLL. He precomputed all of these and then ran them all through a solver in order to get optimized (and also obfuscated) setup/scrambles. His version also has a timer, which mine does not. Yet/if ever.

Brian.
 
Double layers turns only (r,l,f,b,d,u)
Use only double layers turns for F/B, and single layer turns for U,D,L,R
Use only double layers turns and M moves
Use double layers turns for u, all other moves would be single
 
The full 288 PLL cases form a group. Apply one, then apply another one, you still end up with one of the 288 cases. (Note that the 288 cases includes the trivial ones: the identity, U, U', and U2.) You can generate any case by applying one PLL, and then applying the correct one that will generate the one you want starting from the result of the first one.
 
@PJK: Those are interesting ideas that I think I could code relatively easily. I particularly like only applying this to one or a few faces. However, I'm not very fond of double layer turns (or slices for that matter). I'm primarily writing this for me (though I plan to release it to the public if anyone wants it), so I'd like to keep this to all single face turns and a cube rotate before and after. You've got me thinking though...

@CuBerBruce: Neat. I had previously observed that PLLs successively applied transformed the cube from one PLL to another, and of course that some PLLs are not symmetrical, but rather set up other PLLs.

I think coming up with the mappings of what 2 PLLs yield a third PLL might be sort of difficult. There are 210 combinations (permutations?) of 2 PLLs. Speaking of numbers, how did you come up with the figure of 288 PLL cases?

I could see you saying there are 21 x 4 = 84 combinations to include the 4 AUF cases. I could see you saying there are 21 x 4 x 4 = 336 cases to include AUFs and the 4 orientations of the cube about the y face. I could see you saying there are 336 + 4 = 340 combinations to include the 4 states of "none", U, U', and U2 (and no corresponding PLL) . But where does 288 come from?

Brian.
 
^ Ah I see. Most of the 21 look different for each rotation about the y axis (like the Js you mentioned, and the Us, As, etc), but several are symmetrical and look the same when set up from different cube y orientations.

So most of the 21 PLLs have 4 "versions", but some are exceptions. I think I've found all the exceptions, but I come up with 73 total "versions" (before any AUF math) instead of 72, so I must be missing one. Exceptions:

H: Only 1.
Z: Only 2.
N1: Only 2.
N2: Only 2.
E: Only 2.

Total of 9 .

Remaining PLLs: 21 - 5 = 16 . At 4 orientations per alg: 16 x 4 = 64

64 + 9 = 73

What did I miss?

Brian.
 
^ Ah I see. Most of the 21 look different for each rotation about the y axis (like the Js you mentioned, and the Us, As, etc), but several are symmetrical and look the same when set up from different cube y orientations.

So most of the 21 PLLs have 4 "versions", but some are exceptions. I think I've found all the exceptions, but I come up with 73 total "versions" (before any AUF math) instead of 72, so I must be missing one. Exceptions:

H: Only 1.
Z: Only 2.
N1: Only 2.
N2: Only 2.
E: Only 2.

Total of 9 .

Remaining PLLs: 21 - 5 = 16 . At 4 orientations per alg: 16 x 4 = 64

64 + 9 = 73

What did I miss?

Brian.
V permutation: Only 2
 
^ I'd normally defer to your obvious experience, but I think V has all 4 unique "versions" about the 4 y orientations of the cube. Even if you were correct, that would leave us with 71 total instead of 72. Either I'm missing something, or Kenneth is, and I suspect it's not Kenneth. :p

Brian.
 
@CuBerBruce: Neat. I had previously observed that PLLs successively applied transformed the cube from one PLL to another, and of course that some PLLs are not symmetrical, but rather set up other PLLs.

I think coming up with the mappings of what 2 PLLs yield a third PLL might be sort of difficult. There are 210 combinations (permutations?) of 2 PLLs. Speaking of numbers, how did you come up with the figure of 288 PLL cases?

I could see you saying there are 21 x 4 = 84 combinations to include the 4 AUF cases. I could see you saying there are 21 x 4 x 4 = 336 cases to include AUFs and the 4 orientations of the cube about the y face. I could see you saying there are 336 + 4 = 340 combinations to include the 4 states of "none", U, U', and U2 (and no corresponding PLL) . But where does 288 come from?

Brian.

There are 4 LL corner cubies: 4! = 24 permutations.
There are 4 LL edge cubies: 4! = 24 permutations.
Corner parity must be the same as edge parity, so only half the total permutations are possible.
24*24*(1/2) = 288.

Most of the 21 PLL cases correspond to 16 permutation cases. Take U-perm, for instance. Each of the two U-perms cycles three edges relative to the four corners and 4th edge. There are 4 possible choices for the fourth edge (and the four corners whose positions are determined with respect to that edge). That 4th edge has 4 possible locations. 4*4 = 16 permutations for each of the two U-perm cases.
 
^ Ah I see. Most of the 21 look different for each rotation about the y axis (like the Js you mentioned, and the Us, As, etc), but several are symmetrical and look the same when set up from different cube y orientations.

So most of the 21 PLLs have 4 "versions", but some are exceptions. I think I've found all the exceptions, but I come up with 73 total "versions" (before any AUF math) instead of 72, so I must be missing one. Exceptions:

H: Only 1.
Z: Only 2.
N1: Only 2.
N2: Only 2.
E: Only 2.

Total of 9 .

Remaining PLLs: 21 - 5 = 16 . At 4 orientations per alg: 16 x 4 = 64

64 + 9 = 73

What did I miss?

Brian.
V permutation: Only 2

V Permutation has 4, not 2.

It's N-Perm that's being over-counted. N-Perm is a rather tricky one. There are only 2 angles for each of N1 and N2, but a U2 (which is an "AUF") changes the N-Perm from one angle to the other. So (let's say we're just taking N1), if you try the two angles and also apply the 4 "AUF" possibilities, you get 4 distinct permutations each duplicated twice instead of 8 distinct permutations. So in effect, N1 and N2 are each one case.

To make that more clear. take the case where UFL and UBR are swapped and UF and UB are swapped. Apply U2. Now ULF and URB are swapped and UL and UR are swapped. This looks like the same N-Perm case rotated *90* degrees.

And PLL skip, of course, is the 72nd case.
 
Back on topic: Anyone got any other ideas for transforming algs? Maybe I shouldn't bother with any more, as it's really just one alg that I'm able to recognize, even when transformed into one of 28 ways that my program does it.

Or maybe I'll just find more setup algs for this PLL and include them in the program to try to further conceal this PLL.

Brian.
 
I think the best recommendation is cuBerBruce's, use two PLLs with a random AUF in between. You'll end up with a PLL. Organize them into families (their letter gives their family) and be sure not to pick two from the same family so they can't undo each other, i.e. a T can't undo a G, only a T can undo a T.

Having multiple versions of each PLL to pick from is also a good idea.
 
Last edited:
Back
Top