ZZ/ZB Home Thread

[Pyjam]

Hi again.

I added the LPELL cases for the back slot here :
http://www.speedsolving.com/forum/sh...l=1#post767371

I don't know how to remove the useless attached image...

[porkynator]

Hi everyone.
I don't post often in this thread, although I'm a ZZ user, but I don't think this random idea deserved a new thread.
A few weeks ago I decided to find my own approach to the so-called "missing link", that is to say permuting the corners while finishing the Left Block (or the Right Block) to put yourself in a < R, U > move group.
I found a method which is mostly intuitive: it requires only two 5-moves algorithms.
I didn't make any image to explain this, mainly because I don't know any easy way to do it, and I didn't want to learn one only for this. To simplify, I named the corners this way:
FRD: 1
RBD: 2
URF: 3
UFL: 4
UBR: 5
ULB: 6
I use the number to refer both to positions and corner, so I might say "corner 1 and 2" or "position 3".
Obviously, corners orientation doesn't matter at all, so if I say "place corner X in position Y" I mean you can place it there with any orientation.
My approach works after finishing the first block (which in my explanation will be the Right Block).
Now, to the method, which is divided in two very easy steps:

Step 1: Place corners 1 and 2
This step is supa-easy and supa-fast: you simply have to place corners 1 in either position 1 or 2, and the corner 2 in the remaining D-layer position. To make it short, place the D-layer corners in the D-layer (either placed correctly or swapped).
This can be easily looked-ahead while finishing the right block. Back when i thought of it, I also did some brute-force math:
HTM:
Average: 1.8
Worst Case: 3
QTM:
Average: 2.4
Worst Case: 4

Step 2: Actually permute corners
Now the tricky part: you have to recognize the U-layer corners permutation. It can be one of 3 cases: permuted correctly, orizontal swap or diagonal swap.
Combining this 3 cases with the 2 possibilities of the D-layer (corners permuted or swapped) you have a total of 6 cases.
I use this code:
N = corners of the U-layer permuted correctly
O = corners of the U-layer off by an orizontal swap
D = corners of the U-layer off by a diagonal swap
n = corner of the D-layer placed correctly
s = corners of the D-layer swapped.
So for example Ns means that the corners of the U-layer are ok while the 2 corners of the D-layer are swapped.

Case 1 and 2: Nn and Ds
Nothing to do, Yay!

Case 3 and 4: On and Os
The algorithm to use here is L' U R U' L
For the case Ns place the two swapped corners in positions 3 and 5, use the alg, and here you go.
For the other one, place the swapped corners of the U-layer in positions 4 and 6, use the alg, and here you go.

Case 5 and 6: Dn and Ns
The algorithm is L' U R2 U' L
The position of the U-layer is irrelvant. Yay!

I did some math also here and, not counting the AUFs, the moves this step requires are:
HTM:
Average: 25/6 (~4.167)
Worst Case: 5
QTM:
Average: 13/3 (~4.333)
Worst Case: 6

Total
HTM:
Average: 179/30 (~5.967)
Worst Case: 8
QTM:
Average: 101/15 (~6.733)
Worst Case: 10

PROs:
-Mostly intuitive
-8 moves... let's 9 with the AUF it's, in my opinion, a good price for a 2GLL

CONs:
-Recognition it's still a pain. I don't know if will be any suitable for speedsolving.
-If you're used to solve the 2 blocks together, building one first and then the other one can be unexpectedly slower.

I played with this approach for a while, but I didn't get any nice result. I will try to improve with it, maybe with OH, but I'm not very optimist. If someone else wants to try, please tell me if you find it somehow nice or a total crap.

[Pyjam]

For the images, you could use Conrad Rider's Visualcube : http://cube.crider.co.uk/visualcube.php

Your 2 algs:

Case 3 and 4: On and Os
The algorithm to use here is L' U R U' L
For the case Ns place the two swapped corners in positions 3 and 5, use the alg, and here you go.
For the other one, place the swapped corners of the U-layer in positions 4 and 6, use the alg, and here you go.


Case 5 and 6: Dn and Ns
The algorithm is L' U R2 U' L
The position of the U-layer is irrelvant. Yay!


You can add arrows.

[porkynator]

For the images, you could use Conrad Rider's Visualcube : http://cube.crider.co.uk/visualcube.php

[..]

Thanks, I'll try, if I need it again

[mDiPalma]

porkynator, i'm not sure how to tell you this

but i hope this picture will suffice: click

[Robert-Y]

That's quite an interesting idea porkynator. I was thinking of inverting your idea so that you place 4 and 6 first, so the algs for permuting the corners become D' R U R' D and D' R U2 R' D, but this way, recognition might become even more difficult :P

[Athefre]

The idea isn't really new. The biggest problem with making ZZ-d work is that so often people want to rely on making it easy to recognize by placing a couple of corners then add on to that the five moves it takes to permute the corners. Niklas is only seven moves. An opposite swap isn't much longer.

[porkynator]

porkynator, i'm not sure how to tell you this

but i hope this picture will suffice: click

That made me laugh, I didn't expect this kind o reaction! I'm waiting for some feedback if you want to try this method...

That's quite an interesting idea porkynator. I was thinking of inverting your idea so that you place 4 and 6 first, so the algs for permuting the corners become D' R U R' D and D' R U2 R' D, but this way, recognition might become even more difficult :P

I knew I couldn't be the first to think of such an easy idea, but I couldn't find anything about it... placing 1 and 2 first seemed more natural to me, and I went on with finding algs and movecounts because I knew that I could easily brute-force all the cases to find the average moves.

The idea isn't really new. The biggest problem with making ZZ-d work is that so often people want to rely on making it easy to recognize by placing a couple of corners then add on to that the five moves it takes to permute the corners. Niklas is only seven moves. An opposite swap isn't much longer.

That was the reaction I expected! Yes, this is not more efficent than a Niklas at the end of the solve, but maybe with may approach you can look-ahead some moves for the second block while you do the algorithm... or maybe you can't, and this is just a bad idea. But it's still an idea.

[Athefre]

Yeah, I don't mean to seem harsh. This stuff needs to be explored and there are very few doing it.

[porkynator]

It's me again, but on a different topic this time.
I've done an avg100 in a linear-FMC style to see what my movecount for EOL+F2L was.
Here it is:

number of times: 100/100
best time: 20.00
worst time: 46.00
best avg5: 28.33 (σ = 1.53)
best avg12: 30.30 (σ = 4.06)
best avg100: 33.22 (σ = 4.08)

These are obviously number of moves, not times. I didn't keep track of the EOL movecount, but I think I'm around 7 moves on average. I think 33 moves on average isn't that bad, but I hope I can be sub30 with some practise. What do you think about it?