The New Method / Substep / Concept Idea Thread

[Neuro]

It seems to me that a modified version of SSC-Domino would give near optimal efficiency for a human approach to the Kociemba algorithm.

Solving EO Line on Left with any E slice edge usually takes ~5 moves
Domino redux is super efficient, breaking to ~12 moves
Domino usually takes ~14 moves

So without much influencing of pieces, we easily get a 31 move method that usually gets 0 moves even with fixed centers. As a mathematical approach, the method is quite good, as it very quickly reduces the cube from <U, U', U2, F, F', F2, B, B', B2, D, D', D2, R, R', R2, L, L', L2> to <U, U', U2, F2, B2, D, D', D2, R2, L2> that is achievable by humans and consistently gives very low movecounts. While I don't think it would be good for anything other than (maybe) FMC, I think this is an interesting addition nonetheless.

 

[sqAree]

The problem is that, as far as I understood, the domino stage has the same complexity as solving a whole 3x3, thus it might be very difficult to find near-optimal domino solutions (for humans).
When I learned SSC I tried to use exactly this for FMC and I failed miserably. But maybe with a bit of training it could be done, I'd like to know.

 

[shadowslice e]

It seems to me that a modified version of SSC-Domino would give near optimal efficiency for a human approach to the Kociemba algorithm.

Solving EO Line on Left with any E slice edge usually takes ~5 moves
Domino redux is super efficient, breaking to ~12 moves
Domino usually takes ~14 moves

So without much influencing of pieces, we easily get a 31 move method that usually gets 0 moves even with fixed centers. As a mathematical approach, the method is quite good, as it very quickly reduces the cube from <U, U', U2, F, F', F2, B, B', B2, D, D', D2, R, R', R2, L, L', L2> to <U, U', U2, F2, B2, D, D', D2, R2, L2> that is achievable by humans and consistently gives very low movecounts. While I don't think it would be good for anything other than (maybe) FMC, I think this is an interesting addition nonetheless.

Yeah I've tried this but afaik it's only really good for a sub-35 move backup solution. (Though I suppose it could be good if you really put some effort into learning domino and tricks there). Ultimately it suffers from similar problems to normal SSC: the lat stage is actually pretty difficult for humans to master effectively

 

[Neuro]

The problem is that, as far as I understood, the domino stage has the same complexity as solving a whole 3x3, thus it might be very difficult to find near-optimal domino solutions (for humans).
When I learned SSC I tried to use exactly this for FMC and I failed miserably. But maybe with a bit of training it could be done, I'd like to know.

Yeah I've tried this but afaik it's only really good for a sub-35 move backup solution. (Though I suppose it could be good if you really put some effort into learning domino and tricks there). Ultimately it suffers from similar problems to normal SSC: the lat stage is actually pretty difficult for humans to master effectively

The main reason I posted this was to start discussion on super efficient human solutions; not necessarily to create a better speedsolving method. I'm very interested in making a method that can be solved entirely by hand reaching almost CPU efficiency in a near-linear fashion; it doesn't need to be practical/fast/easy, just achievable by a human solver. And yes, I agree with the domino redux issue, it's very hard for humans to find an efficient solution. So I would love to start a discussion on finding a near optimal human solution to the puzzle, let me know what you think can be done!

 

[alwin5b]

Because of @Neuro s post I looked at the SSC method. I don't think the method I came up with has a particularly low move count, but I'll share it anyway.

1. EOLine on left and setup for OL5C.
2. OL5C
3. bring the cube into a state where the 2x2x2 block containing the LBD corner is solved.
4. build the 2x2x1 block containing the FDL corner and place it such that it can be solved with an F2 turn while simultaneously reducing the corners to the <R2,U> group.

cube is now reduced to <R2, U> group.

5. solve the F2L while making sure that you either skip the LL or can finish LL with a U-Perm (anti-phasing the edges guarantees a U-Perm).
You can also place the UR edge and its adjacent corners in DR position and pretend the actual DR edge (+corners) were the UR edge (+corners), then do an R2 at the end of the solve.
6. U-Perm or skip.

Edit: step 5. and 6. can be done better. I think building a 2x2 block on the U layer instead of finishing F2L should be better. then you would have to apply one of 120 algorithms to finish the cube. Or build a 2x2 block on U and place one corner on D to reduce to 24 cases. But I fear these algorithms can sometimes be long, I don't know for sure.

 

[Arc]

I think @Arc 's method is best:

1. Track CP through square (without DBL fixed, instead keeping track of where the faces that will become <R,U> are--he calls it "floating CP" which is pretty apt)
2. Solve last pair + CP. I don't know how he does this one, but e.g. force last edge somewhere + algorithm would be ~6 CP * 3 CO * 7 DLF = 116

Last pair + CP is just like 2GR's CPLine except you pair the edge with the corner before solving it with an F.

 

[Neuro]

Ok so I gave some thought as to how us as humans tend to tackle the problem of curbing and I have concluded that humans are terrible problem solvers.

We need to SEE progress (directly solving pieces) which is entirely different from a computer solution that'll solve based on branching solutions (i.e. Kociemba and Korf algs)

So we need to come up with some way to directly solve pieces that's very efficient. This leads us several ways (human methods) to break down a solve; like Roux and Petrus.

So we know there are 12 edges and 8 corners for 20 total pieces. As a realistic human breakdown, I think breaking it down into two main steps that each solve 10 pieces would be a *decent* starting point. Take the Roux Method: F2B solves 4/8 corners and 6/12 edges. CMLL/LSE is practically L10P, solving L4C and L6E.

Both perfect and imperfect breaks can be used, and that's where method development comes into play. Non-perfect breaks have a possibility of being more efficient AND easier to understand. In fact, you can even solve in uneven breaks such as 3phase solutions; such as corners, 6 edges, last 6 edges.

We need to keep experimenting to make a better, more efficient method that a human can reliably use. My goal would be a method <=35 moves. Disregard how easy or even how fast they are, just something a human can reliably do in a (near) linear fashion; no insertions/NISS.

As a start, I'm using Roux broken into linear F2B and either L4C/L6E or L6E/L4C

 

[Oliver1010]

I'm too lazy to see if anyone already came up with this:
Solve the cross edges with one edge flipped.
Solve f2l.
Orient the last layer with one alg. One of the edges will be oriented incorrectly, but that will be fixed later. You have 4 algs to choose from, so choose the easiest one.
Solve PLL+ 2 flipped edges with 1 alg.

This is not meant to be a standalone method

 

[Abram Lookadoo]

new method (EBXX)(XX represents a 2 step ll+ls method)

1) edge
place a single edge piece in DB
2) 3 F2l blocks
build 3 1x2x2 blocks to complete F2l-1
3-solved) ll+ls
any way you want, solve ll+ls

 

[shadowslice e]

new method (EBXX)(XX represents a 2 step ll+ls method)

1) edge
place a single edge piece in DB
2) 3 F2l blocks
build 3 1x2x2 blocks to complete F2l-1
3-solved) ll+ls
any way you want, solve ll+ls

So heise more or less?

 

[Cubewerkz]

Here is a 3x3 beginner method that I use when I learn to solve rubik's in the 80's. I don't seem to have seen anyone use it before or shown on youtube.

Basically there are 26 pieces on the cube to be solve. Since 6 centers orientation does not matter. Only 8 corners and 12 edges to solve. All approaches differ on how we divide to solve these 8 corners and 12 edges in stages and how we tackle orientation and permutation.

1) Solve 8 corners of a 3x3 (Any 2x2 methods can be used here). For beginner, 2 algorithms using layer by layer should be enough.
2) Solve top and bottom layers(4 edges each) together using equator. Use Edge insertion intuitively. This is mainly intuitive (mainly RER', R'ER, RE2R',R'E2R', LE'L', L'EL, LE2L', L'E2L') using keyhole on one layer while solving other layer until last 3 edges are solve on each side. Solve last 2 edges by some setup together. Top and Bottom will be solved.

3) Last 4 middle edges. You will have either 4 flipped edges, 2 flipped edges or no flipped edges (solved state). Use edge flipping algorithm for 2 opposite flip edge (M'UM'UM'U2 MU MU MU2)

Here is video of it

Just wondering whether it can be listed as a method in the wiki for beginner 3x3.

 

[shadowslice e]

Here is a 3x3 beginner method that I use when I learn to solve rubik's in the 80's. I don't seem to have seen anyone use it before or shown on youtube.

Basically there are 26 pieces on the cube to be solve. Since 6 centers orientation does not matter. Only 8 corners and 12 edges to solve. All approaches differ on how we divide to solve these 8 corners and 12 edges in stages and how we tackle orientation and permutation.

1) Solve 8 corners of a 3x3 (Any 2x2 methods can be used here). For beginner, 2 algorithms using layer by layer should be enough.
2) Solve top and bottom layers(4 edges each) together using equator. Use Edge insertion intuitively. This is mainly intuitive (mainly RER', R'ER, RE2R',R'E2R', LE'L', L'EL, LE2L', L'E2L') using keyhole on one layer while solving other layer until last 3 edges are solve on each side. Solve last 2 edges by some setup together. Top and Bottom will be solved.

3) Last 4 middle edges. You will have either 4 flipped edges, 2 flipped edges or no flipped edges (solved state). Use edge flipping algorithm for 2 opposite flip edge (M'UM'UM'U2 MU MU MU2)

Here is video of it

Just wondering whether it can be listed as a method in the wiki for beginner 3x3.

It's a variant of corners first isn't it? In fact, I might be tempted to call it a variant of Varasano though not quite as optimised as it (though as it's for beginners this would go without saying).

 

[Cubewerkz]

It's a variant of corners first isn't it? In fact, I might be tempted to call it a variant of Varasano though not quite as optimised as it (though as it's for beginners this would go without saying).

This is a beginner 3x3 method which is a corner first method and thus require someone to know how to solve 2x2 as a prerequisite. I mentioned that this method was used by me intuitively in the 80's. I am 47 years old. I do not know Varsano Ortega back then nor now and have only just seen his method just after you mentioned. So it was developed independently. There is no Internet back then. Solving the 2 layers together is mainly intuitive. He called it the L6E for the last part. For my case. I don't have fixed buffer piece.(Both FR and FL) can be used. I kept the 2 layers top and bottom instead of left and right. There is some similarities with Varasano method but it is really developed independently and back then I do not know about cubing notation and know how to define a sequence of moves as algorithms.

 

[Abram Lookadoo]

new method (BPSL)(block-pair-slot-layer)

1) block
solve a 2x2x3 block in the BD
2) DF+Eo
orient the DF, FR, and FL edges while moving edge DF into place
3) F2l-1
build an F2l pair while simultaneously placing the other F2l pair
4) eocpls
place the final F2l pair while simultaneously orienting all the edges, and permuting all the corners (1/96 algs)
5)2gll
solve co and ep, solving the cube (1/84 algs)

 

[Teoidus]

Seems like it could be an alright Petrus variant, but I don't see an advantage over other methods

 

[efattah]

We need to keep experimenting to make a better, more efficient method that a human can reliably use. My goal would be a method <=35 moves. Disregard how easy or even how fast they are, just something a human can reliably do in a (near) linear fashion; no insertions/NISS.

If you allow 1LLL size algorithm sets it is definitely doable. Modifying LMCF for 2000+ algorithms achieves it in a very straightforward way:
1. Learn TEG-1/TEG-2 (full EG + TCLL + TEG1/2), except learn 4-8 variants of each algorithm with different effect on the U/E layer edges
2. During inspection, you set up your partial face on the bottom (required for TCLL/TEG) and then you use 0-2 slice moves to set up one E slice edge and one U slice edge into trigger positions
3. You execute one of 4-8 variants of the corners algorithm which simultaneously solves the two trigger edges (this is sort of like multiple CMLL's in Roux which affect the edges in different ways)
[ you have just solved 10 pieces in the first step, except that half the time an additional piece is also solved at random, so up to 11 pieces solved ]
4. Now you finish the cube with traditional LMCF with all the algorithms (this takes around 550 algorithms from here onward)

The total would be around 1600 algs for the first step and 550 for the second step, around 2150 algorithms. You save around 6 moves off regular LMCF, so the average goes from 41-43 down to 35-37. Because 2 U slice edges are solved in the first step, once you rotate, the L face barely moves so you have virtual RrUM for the remainder of the solve.

 

[Teoidus]

I can achieve sub-30 movecounts pretty straightforwardly as well: just memorize ||G1|| + ||G2|| algorithms and use kociemba's 2phase. It's quite straightforward really.

 

[xyzzy]

I can achieve sub-30 movecounts pretty straightforwardly as well: just memorize ||G1|| + ||G2|| algorithms and use kociemba's 2phase. It's quite straightforward really.

Orders of magnitudes, though. efattah's idea has an alg count "only" in the thousands, whereas you're thinking of something in the tens of millions. (Learning thousands of algs sounds ridiculous now, but just a decade ago people said the same thing about full ZBLL and look at where we are today.)

 

[Pyjam]

I have my doubts.

Spoiler

 

[Teoidus]

Orders of magnitudes, though. efattah's idea has an alg count "only" in the thousands, whereas you're thinking of something in the tens of millions. (Learning thousands of algs sounds ridiculous now, but just a decade ago people said the same thing about full ZBLL and look at where we are today.)

You're right; I just don't think changing an algorithm count from 700 to 1600-2000 is a "straightforward" way to achieve low movecounts. We've definitely pushed algset size limits past what people 10 years ago could have imagined, but I can't imagine anyone calling Jabari/Tao's learning ZBLL a straightforward task.