# Optimal Tripod Finish Analysis



## cuBerBruce (Jan 20, 2009)

I have used Cube Explorer to generate optimal sequences in FTM for all "tripod finish" cases. (See also this thread about the tripod finish: http://www.speedsolving.com/forum/showthread.php?t=3275

My analysis summary can be found at: http://cubezzz.duckdns.org/drupal/?q=node/view/132

The tripod finish includes 7776 total positions, or 1317 cases when reduced by the symmetry of the tripod configuration. The worst case was 15 face turns (289 positions) and the average was less than 12.75 face turns.


----------



## mrbiggs (Jan 20, 2009)

Doesn't cube explorer not guarantee optimal solutions?

(Not trying to be a jerk, I'm just very interested in the topic and I'm trying to learn more about cube programs)


----------



## cuBerBruce (Jan 20, 2009)

mrbiggs said:


> Doesn't cube explorer not guarantee optimal solutions?



In its normal (fast) solving mode, it does not. But it also allows you get optimal solutions.


----------



## MistArts (Jan 20, 2009)

Do you think the average would be reduced and the cases would be "humanly-optimal" when edges are oriented correctly?


----------



## cuBerBruce (Jan 20, 2009)

MistArts said:


> Do you think the average would be reduced and the cases would be "humanly-optimal" when edges are oriented correctly?


First of all, as Stefan would probably say, what do you mean by the phrase "when edges are oriented correctly"?

If you mean Petrus-style edge orientation, for instance, you have a choice of three 2x2x3 blocks with which to define edge orientation with respect to. Which one you choose may determine whether the edges are oriented or not. If you use an edge orientation convention like what is typically used in BLD solving, you are essentially reducing the symmetry you have with the tripod configuration. <U2, D2, L2, R2, F2, B2>-style edge orientation is perhaps the logical choice for defining edge orientation with the tripod, as it preserves the 6x symmetry that you have with the tripod, but it's probably unfamiliar and counter-intuitive to most speedcubers.


----------



## Stefan (Jan 21, 2009)

cuBerBruce said:


> <U2, D2, L2, R2, F2, B2>-style edge orientation is perhaps the logical choice for defining edge orientation


I don't understand. When we use let's say <U, D, L, R, F2, B2>, then I can say the UR edge, when at FR, is oriented correctly. Because I can move FR to UR with the allowed moves. I don't see how to use your above suggestion, because those moves don't allow me to move pieces between the three locations in the tripod at all. Or put differently, it gets me three groups of reference orientations (one for each inner slice) and they're independent, so it doesn't help me at all to define whether an edge located in the wrong inner slice is correctly oriented. Please clarify.


----------



## cuBerBruce (Jan 21, 2009)

StefanPochmann said:


> cuBerBruce said:
> 
> 
> > <U2, D2, L2, R2, F2, B2>-style edge orientation is perhaps the logical choice for defining edge orientation
> ...



In <U2, D2, L2, R2, F2, B2>-style edge orientation, any quarter-turn is considered to change the orientation of all four edges that are moved. So to move an edge within the tripod, you will need to make two quarter-turns (that move that edge) to preserve its orientation. The main beauty of this edge orientation convention is that it is that it is "M-symmetric" (whole cube symmetry) in Hoey's symmetry terminology. So you don't even need to define which face is which in order to determine which edges are oriented.

EDIT:
Okay, I think Stefan is pointing out that <U2, D2, L2, R2, F2, B2> doesn't really define an edge orientation in the same way that <U, D, L, R, F2, B2> does.

If you look at the positions in the <U, D, L, R, F2, B2> group, all the edge cubies can occupy any edge position. Not only that, but at each position, a given edge only can have one specific orientation. Thus, the the group can be said to _define_ a specific edge orientation scheme. From this, it can be _derived_ that the move F will happen to change the orientation of the four edge cubies that are permuted by the move (regardless of which edge cubies occupy the positions that are affected). Of course, this also holds for F', B, and B'.

With the <U2, D2, L2, R2, F2, B2> group, it is not the case that all edges can be moved to any edge position. Therefore, this group does not _define_ an edge orientation in the same way as the <U, D, L, R, F2, B2> group does. However, the edge orientation scheme that I intended to refer to has some similar properties to the edge orientation scheme that can be defined by the <U, D, L, R, F2, B2> group. For both schemes, any face turn either changes the orientation of all edge cubies that are moved by the turn, or changes the orientation of none of the edge cubies. In the case of <U, D, L, R, F2, B2>-based edge orientation, all face turns except F, F', B, and B' preserve orientation of each cubie. Or alternatively, the listed generators and multiples of those generators are the only face turns that preserve orientation. In the case of edge orientation scheme I was intending to refer to, the only face turns that preserve orientation are the half-turns.

So I guess the similarity between the way face turns affect edge orientation in these schemes, and the way that the face turns allowed or not allowed by the groups <U, D, L, R, F2, B2> and <U2, D2, L2, R2, F2, B2> correspond with the face turns that preserve orientation or alter orientation of the pieces moved in these edge orientation schemes is what makes me want to think of this M-symmetric edge orientation scheme as <U2, D2, L2, R2, F2, B2>-style edge orientation. If we don't call it that, then what should we call it? (I also note that the Cube Explorer documentation alludes to this edge orientation scheme without actually defining it or naming it.)


----------

