CFOP Superman’s clairvoyance (OLL Dot case to PLL Guessing)

[Tito_H]

Some cubers comment that they want to avoid OLL Dot case, and use partial edge control to avoid it before finishing F2L.

I assume that this is because its typical solve (R U2 R2 F R F' U2 R' F R F') is 14 QTM which is longer than the average OLLs' 10 (?) QTM, and also because it uses non-ergonomic F/F' turns 4 times.

I asked Superman what he thought about the following OLL1 case. He replied to me “I like OLL1, because I can guess which PLL will be, looking at only U & F faces. So, I can proceed with OLL & PLL with my eyes closed, without a hault.”

What! How?
Can you guess which PLL will be?

OLL1

(Source: https://ruwix.com/online-puzzle-simulators/)

 

[bcube]

What! How?
Can you guess which PLL will be?

Try to analyze the move sequence you provided. What does it do?

1. Obviously, it orients the pieces in the top layer
2. It cycles corners: URF -> URB -> ULF -> URF as well as edges: UF <-> UR and UL <-> UB

By applying knowledge from above points to your specific case on the picture, you should be able to determine what PLL case you will get by executing the move sequence you provided.

 

[Tito_H]

Thanks for your insight.

I am impressed by your way to find out where each CP and EP will go after executing the OLL algorithm.

Superman explained some more to me.

He used the same method as you described. For my understanding he marked the each face as follows.

He showed me from where these faces would come, executing reverse scramble of OLL alg. The result was as follows.

(Corners)

(Edges)

Now he explained how to guess its PLL case. He used the knowledge of PLL 2-side recognition method, using the following COLL swap types and BH recognition method.

(6 COLL swap types)
A&B: Adjacent, A&C: Same -> No swap
A&B: Adjacent, A&C: Opposite -> Diagonal swap
A&B: Same, A&C: Adjacent -> Front swap
A&B: Same, A&C: Opposite -> Right swap
A&B: Opposite, A&C: Adjacent -> Back swap
A&B: Opposite, A&C: Same -> Left swap

In this example, A is , B is , C is . So, this corresponds to a Diagonal swap, which is either E, N, V, or Y perms.

BH recognition method comes next.
In this example, ❶is ❷is ❸is ❹is, which is “C x O”.

Judging rom the above 2 things, the case is found to be a E perm.

Mission completed!

Finally, he also said “In the OLL1 Dot case, you can also use Blocks recognition method without so much hassle.”

I will not describe it here, but you can find out what he mean.

I hope this Dot OLL1 (I call it Darth Vader’s Fighter) will be liked a little bit more.

 

[bcube]

Thanks for your insight.

My pleasure . Use whatever recognition method works best for you. To me personally, your method is unnecessarilly overcomplicated :-(. Let me outline my full thought process.



As you know already, when considering edges alone, only UF and UB need to be swapped, meaning that URF and ULF corners need to be swapped as well.

As shown in my previous message, these cycles can be easily seen - corners: URF -> URB -> ULF -> URF, edges: UF <-> UR and UL <-> UB.

If you use the most left hand side button and the most right hand side button on the simulator, you can easily trace individual pieces one by one.

Take URF and place it to URB (from unsolved it becomes unsolved).
Take URB and place it to ULF (from solved it becomes unsolved).
Take ULF and place it to URF (from unsolved it becomes solved).
Therefore, you will end up with ULB and URF solved, and ULF and URB unsolved.

Repeat for edges.
Take UF and place it to UR (from unsolved it becomes unsolved).
Take UR and place it to UF (from solved it becomes unsolved).
Take UB and place it to UL (from unsolved it becomes unsolved).
Take UL and place it to UB (from solved it becomes unsolved).
Therefore, you will end up with all 4 edges unsolved.

However, notice that the current UF edge needs to go to the UR place, current UR edge needs to go to the UB place, current UB edge needs to go to the UL place, current UL edge needs to go to the UF place.

This can be done by a U' move. By executing a U' move, all edges will be solved, and corners go from ULF and URB swapped to URF with URB swapped, and ULF with ULB swapped. I don´t know PLL case namings, sorry.

 

[Tito_H]

Thanks for your full thought process with thorough explanation.

I understood it completely, although your previous method is more adaptable & suitable for me, since it does not require to consider a parity issue

 

[bcube]

Perhaps you misunderstood my first post in this thread because the point of both my posts was that there is no need to learn and use any kind of COLL swap types and BH recognition method in order to determine what PLL case you will get.

I will take it as that you prefer COLL swap types and BH recognition method over intuitive deduction (nothing wrong with that).

 

[Tito_H]

Sorry to confuse you, but I am pretty sure that I didn’t misunderstand your first post. I here describe what has happened.

I tried to analyze the move sequence of R U2 R2 F R F' U2 R' F R F', using your simulator.

Then, your picture has changed…

to this.

And I could confirme the following 2 points you indicated.

1. It orients the pieces in the top layer
2. It cycles corners: URF -> URB -> ULF -> URF as well as edges: UF <-> UR and UL <-> UB

Next, I applied knowledge from above points to my specific case, as you wrote.

Then, my picture has changed…

to this.

And I could determine that this was the E perm.

Mission completed!

I did what you described in your first post, and duly completed the mission. Neither kind of COLL swap types nor BH recognition method was needed.

I should have written this before I wrote anything to avoid any confusion.

Then, why I wrote my post like that.
It was because I didn’t want to stop thinking at that point. I wanted to apply this new knowledge to my solving style.

As I know I am not good at cycling corners & edges in mind to get its PLL, in which way it would take me several seconds, I thought it better for me to “map” the cycling effects to the original OLL1.

I use PLL 2-side recognition method for which many web sites explain, like these (site, site).

But I thought I could not apply that method well, because “Headlights”, “Bars”, “Lines” etc. would not be kept such when they were mapped to OLL1. And, I thought that COLL swap types & BH recognition method would be more suitable, and I wrote it in my post.

Now I regret a bit to have written that, because later I noticed that the 3 front -side pieces of U face (UFL, UF, UFR) go to the right face (RUF, RU, RUB) as they are, and the 2 right-side pieces of U face (URB, UR) go to the front face (FUL, FU) as they are.
So, “Headlights”, “Bars”, “Lines” etc. will be mostly kept such, and that makes me easily use my normal 2-side recognition method (without COLL swaps or BH).