• Welcome to SpeedSolving.com — the world’s largest puzzle community!

    You’re currently browsing as a guest, which means you have limited access to discussions, resources, member profiles, and community features.

    Join 50,000+ cubers and puzzle enthusiasts from around the world to ask questions, share solves, improve faster, and be part of the community.

    Registration is free, fast, and easy — create your account today.

    Already a member? Log in here to hide this message and start participating.

[Help Thread] FMC Discussion

4x4FMC: 92

Scramble (SiGN notation): f B F2 r' f D' u r U2 D B' f r U' L' D U2 L' u' R' L' B2 f2 F2 u U' D' r' B F' f' U2 R' L' f r2 U' f' u' R2

Solution: (SiGN notation):
F l' F l2 F l b R' b'
R L u' L' u L2 u2
B' d2 F2 B d B' d2 L'

R' D' R2 D2 R' u'
B' L B D' L2 D r
F' R2 F D L D' B' R2 B r'
U B u L U' L' u'

L' y2 x'

U2 R' U2 D R' U2 R U D' R2 U R' U' R' U2 L' U2 B' U2 B U2 L U2 F R' F2 R U' R' U F L2 B R2 U' L2 B2
 
To continue the question: what about premoves on inverse solutions?

Here's a more detailed example:

Say you have the scramble A B C' again. You find the solution of simply F when you apply the pre-moves D E' on inverse. We can write that in the following way.

D E' + C' B A + F

We move the pre-moves to the front

C' B A + F D E'

And invert the whole move set

E D' F' + A' B' C

And there's you're answer, your end solution is: E D' F

----

For anyone wondering why the scramble doesn't come first, here is why it doesn't matter/why we can do pre-moves.

If you think of the "Scramble + Solution" as a long single algorithm, it is essentially a null transformation. We start with a solved cube, then move back to it. We could technically apply it to any cube state. If we do the whole algorithm, we will return to our initial state.

The interesting thing about a null transformation is that, as long as we perform the whole transform, we can start with any of the moves. So our final example of the solution + scramble was:

E D' F + A B C'

If we want we can start with the A, we simply continue through the set of moves until we are back, giving:

A B C' + E D' F

This is the same reasoning behind moving the pre-moves at the beginning.

D E' + C B' A' + F

in entirety is again a null transformation, so we are going to change our starting point to C, and wrap back around.
 
Here's another thing that I thought was really cool that builds off the logic of my previous post.

What if I asked you to find a solution that moved from one scramble to another, rather than the solved state? There's no reason we couldn't solve it with normal methods, it would just take a lot of brain power to put the pieces in the right spot.

Lets say we want to move from the state resulting from Scramble S1 to the state resulting from Scramble S2. One clever solution would be to solve both S1 and S2 individually, then put the solutions together.

S1 + U' V W

S2 + R' S T'

We can invert the S2 solution and attach it to the S1 solution.

S1 + U' V W + T' S R' + S2'

You can see that this solution begins at the Scramble 1 state (since it begins after S1) and ends with the Scramble 2 state (because to return to the solved case, we must apply it's inverse.)

However, this isn't very efficient, because it requires two solves. There is a way to do a single solution where we solve towards a solved state. We just have to move things around.

S1 + (Solution) + S2'

is another null transformation, so we can move things around, such as:

S2' S1 + D' E F'

Where D' E F' is the solution. S2' S1 essentially becomes a long scramble. This allows us to move directly from any two cube states with a single normal solve, which I thought was kinda neat.
 
Oh my god.

Scramble: B' D2 F2 B2 U2 B' U' F2 D F L2 D B' D' L2 B' F2 D B F' D2 U L B' L

Okay. CRAZY.

F2L:
(x') U L2' (x' y) M' U2 M' U2 M2 U2 (x) U R2' U' B' l. [13/13]
COLL:
L' U2 L U' R' U L' U' R2 U' L U R'. [13/26]
EPLL:
(y') F2 U M' U2 M U F2. [7/33]

Zomg.
 
Oh my god.

Scramble: B' D2 F2 B2 U2 B' U' F2 D F L2 D B' D' L2 B' F2 D B F' D2 U L B' L

Okay. CRAZY.

F2L:
(x') U L2' (x' y) M' U2 M' U2 M2 U2 (x) U R2' U' B' l. [13/13]
COLL:
L' U2 L U' R' U L' U' R2 U' L U R'. [13/26]
EPLL:
(y') F2 U M' U2 M U F2. [7/33]

Zomg.
M moves count as two moves. HTM is used for FM. So that's 38.
 
Oh my god.

Scramble: B' D2 F2 B2 U2 B' U' F2 D F L2 D B' D' L2 B' F2 D B F' D2 U L B' L

Okay. CRAZY.

F2L:
(x') U L2' (x' y) M' U2 M' U2 M2 U2 (x) U R2' U' B' l. [13/13]
COLL:
L' U2 L U' R' U L' U' R2 U' L U R'. [13/26]
EPLL:
(y') F2 U M' U2 M U F2. [7/33]

Zomg.
M moves count as two moves. HTM is used for FM. So that's 38.

Ranzha = STM. I believe I've discussed this before. Kthxbai.

EDIT: http://www.speedsolving.com/forum/showpost.php?p=397792&postcount=166
 
Last edited:
What Ranzha likes =/= official, or even the generally accepted norm
And I really don't care if you posted about it once, two months ago, in an unrelated thread. I don't care if you've posted about it a million times.
 
Oh my god.

Scramble: B' D2 F2 B2 U2 B' U' F2 D F L2 D B' D' L2 B' F2 D B F' D2 U L B' L

Okay. CRAZY.

F2L:
(x') U L2' (x' y) M' U2 M' U2 M2 U2 (x) U R2' U' B' l. [13/13]
COLL:
L' U2 L U' R' U L' U' R2 U' L U R'. [13/26]
EPLL:
(y') F2 U M' U2 M U F2. [7/33]

Zomg.
M moves count as two moves. HTM is used for FM. So that's 38.

Ranzha = STM. I believe I've discussed this before. Kthxbai.

EDIT: http://www.speedsolving.com/forum/showpost.php?p=397792&postcount=166

You can't be serious?
 
US Nationals 2010, FMC #2

Scramble: U' L2 D F U2 F2 D' F' D' F2 D B2 D' B' U2 F' R U' (18f)

2x2x2 block: U B2 R2 B L2 (5)
Invert with premoves L2 B' R2 B2 U'.
Block extension: B' U' R' B' R2 (10)
Use premoves R2 B R U B, and start with U B2 R2 B L2.
Finish except for three corners: B U' B' L' B L B' R B R' L U R' . U' L' R (25)
Insert at the period: R' U L U' R U L' U' (31)

Solution: U B2 R2 B L2 B U' B' L' B L B' R B R' L U R2 U L U' R U L' U2 L' R' B R U B (31f)
 
M moves count as two moves. HTM is used for FM. So that's 38.

Ranzha = STM. I believe I've discussed this before. Kthxbai.

EDIT: http://www.speedsolving.com/forum/showpost.php?p=397792&postcount=166

You can't be serious?

Ignoring the bizarreness of someone claiming the rules don't apply to him or her, it did get me thinking about some of the differences in the different metrics.

This has been discussed in other places, but I took a bit of a different approach. I optimally solved 120 random cubes, forty QTM, forty HTM, and forty STM. I would have done more, but my computer is only so fast, and the STM is especially hard on the processor. 120 cubes did, however, turn out to be enough data for statistical significance.

I then compared all the solutions in each metric. All the data has to be taken with a grain of salt, because we don't solve optimally, but hey, that the ultimate goal in FM, right? Haha.

When optimizing for QTM, as we would expect, we have a lot less half and slice turns, at only 5.5% and 3% respectively.

When optimizing for HTM, we have the same number of slice turns, but half turns jump to over 30%.

When optimizing for STM, we get the same number of half turns, and slice turns jump to around 10%.

Move counts are pretty much exactly what we would expect. You can't compare back and forth, because the goal was different, and these results are significant. The one exception is that when solutions optimized for HTM and STM are compared in the STM, they are statistically the same, the results are as follows:

Optimized for HTM, counted in STM: 17.25 +/- .26
Optimized for STM, counted in STM: 17.00 +/- .21

So, there may be some merit to comparing solutions of people competing in the different metrics if they are compared in STM. To know if this were doable we would have to compare human solutions in HTM and STM. But, since STM is not generally accepted, there is not much data to sample human solutions from.
 
I don't have the time right now to type a full response- I will later. But how did you solve cubes optimally for QTM and STM? ACube?
 
The main reason why I like STM over HTM is that I think STM provides more useful cancellations and would, overall, leave no move-count restrictions (except the archaic R L move, being counted as one; and R r, as such. I've seen it done with some freaky notation at one time or another).

Take this as an example:
visualcube.php


This was scrambled with M' D' M' D' M' D' M' D'.

The optimal solution for this is the inverse of the scramble.
In STM, D M D M D M D M. 8 moves.
In HTM, R' L B' R' L U' R' L F' R' L D'. 12 moves.

I do understand that optimally for 120 random cubes, there's no significant difference. However, because of the insignificant difference, why hasn't STM been implemented?
 
I don't have the time right now to type a full response- I will later. But how did you solve cubes optimally for QTM and STM? ACube?

Looking forward to it; I used Cube Explorer to tackle STM (there's a Use Slice Turns option) and I used a command-line adapted version of Cube Explorer to handle QTM--it's available in the download section of the Cube Explorer site. It's especially cool because it can find all optimal solutions, which maybe other programs do, but I haven't seen.

The main reason why I like STM over HTM is that I think STM provides more useful cancellations and would, overall, leave no move-count restrictions (except the archaic R L move, being counted as one; and R r, as such. I've seen it done with some freaky notation at one time or another).

Take this as an example:
visualcube.php


This was scrambled with M' D' M' D' M' D' M' D'.

The optimal solution for this is the inverse of the scramble.
In STM, D M D M D M D M. 8 moves.
In HTM, R' L B' R' L U' R' L F' R' L D'. 12 moves.

I do understand that optimally for 120 random cubes, there's no significant difference. However, because of the insignificant difference, why hasn't STM been implemented?

I'm not convinced that the insignificant difference would carry over to human solutions, just that the data justifies inquiry. We don't know how different human solutions are from optimal solutions in execution, but we do know they are. Earlier in this thread I shared that I had found that there is a significant difference in the number of half turns present.

I think we can all agree that STM has merit. It feels like one move, it's easier to understand commutators like the basic 6f* edge 3-cycle, otherwise certain solving methods must be avoided, and due to randomness we should expect about 9% slice turns in optimal solutions (which we see in STM, not in HTM).

However, if I had to pick, I would stay with HTM for the following reasons: In the search for god's algorithm upper and lower bounds HTM has been the standard for a long time, and I feel fewest moves should be the same. Slice turns definitely feel more "powerful" as single turn. And the kicker, STM is not better enough to justify a change.
 
4x4FMC: 92

Scramble (SiGN notation): f B F2 r' f D' u r U2 D B' f r U' L' D U2 L' u' R' L' B2 f2 F2 u U' D' r' B F' f' U2 R' L' f r2 U' f' u' R2

Solution: (SiGN notation):
F l' F l2 F l b R' b'
R L u' L' u L2 u2
B' d2 F2 B d B' d2 L'

R' D' R2 D2 R' u'
B' L B D' L2 D r
F' R2 F D L D' B' R2 B r'
U B u L U' L' u'

L' y2 x'

U2 R' U2 D R' U2 R U D' R2 U R' U' R' U2 L' U2 B' U2 B U2 L U2 F R' F2 R U' R' U F L2 B R2 U' L2 B2

I meant this solve
 
Back
Top