Skewb method by Milan

[bamilan]

Don't wanna waste your time, so i give a short description of the method i came up with:

1st step: solve 2 corners + 2 centers between them. (intuitive, 3-4 moves on average)
2nd step: solve all centers. (very ez, intuitive, max 2 moves except 1 case which is 3)
3rd step: solve last 6 corners. (729 algs total, max 10 moves)

Don't be afraid of inspection of last 6 corners. Its relatively ez, only orientation matters, it identifies the case. Permutation doesn't matter at all.
Too many algorithms? Most of them are mirrors/backwards of others. 80%+ of them are like [setup - 4 move alg - setup'].
I generated 5 algs for each of these 729 cases, see attachment.

If you don't want to learn all algs, do 3rd step in 2 steps. Try to make 2 subgroups with 20-20 algs in each group(20-20 is example).

Additional info: first 2 steps can be merged, 4.93 moves on average that way. (from 1000 test cases)



Edit: I was totally wrong about that 729 algs. There are only 81 possible orientations.
Edit2: I was totally wrong about that 81. There are 729 possible orientations. It is possible that you got to step3, and you end up with only 1 unoriented corner.

 

[Tim Major]

Hmmm... interesting method. A little similar to Ranzha's method. The corners step seems difficult...

 

[bamilan]

Hmmm... interesting method. A little similar to Ranzha's method. The corners step seems difficult...

I think i was wrong with that 729 algs. Its only 81 algs.
Basic idea is if you have 2 solved corners and all centers solved, then if you orient remaining 6 corners the only case you can end up is solved cube. So the num of cases for the last 6 corners are the possible orientation of them, which is 81.

 

[Jakube]

The maximum for the 2nd step 3 moves. Just do one sledgehammer on a solved skewb. This centers can only be solved in 3 moves. At least I cannot find a shorter solution.

But I like the 3rd step. I thought of a similar method myself, but it never occured to me, that the permutation of the corners is automatically solved while solving the orientation. Clever.

 

[Tim Major]

They can be oriented but not permuted though. Can you do a video of a few examples please?

 

[bamilan]

The maximum for the 2nd step 3 moves. Just do one sledgehammer on a solved skewb. This centers can only be solved in 3 moves. At least I cannot find a shorter solution.

Yes i know of that case, but it is very easy to avoid. Thats the only case you should avoid.
Anyway, this method was planned as first 2 steps merged together, I just decompressed it to 2 steps for easier start for noobs.

 

[bamilan]

They can be oriented but not permuted though. Can you do a video of a few examples please?

I can't, I don't have a skewb

 

[Jakube]

They can be oriented but not permuted though.

Actually they can't. It isn't possible to cycle 3 corners with keeping the orientation.

 

[Tim Major]

Are you using a Skewb sim? Fraps/Bandicam?

 

[bamilan]

Are you using a Skewb sim? Fraps/Bandicam?

Wrote skewb solver. Gave it my ideas, and waited for results (movecounts, num of cases).

 

[Tim Major]

I worked out you were correct about the orientation thing. I had some corners cycles and I tried to orient the corners and two were clockwise.

Recog/recall though...

 

[Ranzha]

I like the idea. Not impossible to implement efficiently, but a pain to hack.

The third step actually has 729 cases, not 81. 81 skewb algorithms is still an absurd number to just learn on a whim. If you can find a feasible way to hack the third step, then I'll be really intrigued.

The only similarity to my method is the first step, which I came up with independently, but I was surprised to find out that I wasn't even the first to come up with it. Acubist was.

 

[bamilan]

Here are all the cases for step3 which can be solved in at most 7 moves.
Try to form the substeps using these algs.

 

[Robert-Y]

Have you considered solving or just permuting another corner whilst solving the rest of the centres? Surely this would cut the number of cases down by a lot, and hopefully it doesn't add much to the move count of step 2...

 

[Jander Clerix]

Wow this method looks really fast and intresting can you maybe make a video of this when you have a skewb?

 

[bamilan]

Have you considered solving or just permuting another corner whilst solving the rest of the centres? Surely this would cut the number of cases down by a lot, and hopefully it doesn't add much to the move count of step 2...

That's a very good idea! I will think about how to do step 2 in en efficient way, to leave only low-movecount cases in step3.

Wow this method looks really fast and intresting can you maybe make a video of this when you have a skewb?

Well, before doing a video i would like to make sure the method has potential. Yau's idea looks very interesting to me, i will experiment with it.

 

[Robert-Y]

I think I've worked out a way doing this method to cut down the number of cases:

Step 1: Solve 2 corners and 2 centres as Milan originally proposed.
Step 2a: Permute any corner next to your block from step 1. (Only one move)
Step 2b: Solve the permuted corner and the rest of the centres. (Only 36 cases at most)
Step 3: Solve the remaining corners (81 cases)

Which gives a total of at most 117 algorithms to learn.

 

[Jander Clerix]

wow looks cool robert

 

[Robert-Y]

You could even cut out 18 cases in the 2nd step, if you choose to always permute the same corner.

For example if UBL and UBR were already solved, you could choose to permute UFR every time, giving only 18 cases for the 2nd step.

 

[bamilan]

I don't see how the step-3 algorithms are 81.

Edit: i see it now