The New Method / Substep / Concept Idea Thread

[Thermex]

Yeah that's with AUFs. Without AUFs, it should be 6! = 720.

If I'm understanding it right, then VOLL is orienting the 6 corners <R,U>? If so, I feel like that figure is a bit more difficult to calculate because symmetries are weirder with CO, but it should be around 9 * (3^3) = 243 without AUFs, and has a lower bound of 243/4 = 60.75 with AUFs

VOLL is not 243 algs, it is exactly 53 because it's the same step as the SOAP method's orientation stage (53 algs) but the permutation of the d-layer corners doesn't matter, meaning your second number was almost correct. I'm skeptical that VPLL is anywhere near the figure you gave but it would need to be explored more if we want to get the exact number.

 

[Teoidus]

Hm, the only way I could see VOLL being that small is if you count both AUFs and ARFs. If so, then you have ~ 3^5/8 = lower bound of 30.375. I'm not sure hwo the SOAP inventor got 53 though, since he also has to preserve corner separation

VOLL isn't 243 algs, but there must be 243 unique cases without AUF. Maybe I got my lowerbound math wrong, but I'm not sure why: 9 orientations for the D layer corners * 3^3 orientations for the U layer corners / at most 4 AUF possibilities for each U layer corner state = 60.75

Perhaps @xyzzy can help with this, he's better at this kind of stuff.

I would still say VPLL is going to be quite large, as your corners can be in any of 6! = 720 permutations. Even if you include AUFs, this will bring down the number of algorithms you need to 6!/4 = 180. If you include both AUFs and ARFs, then every case has 8 possible adjustments -> 6! / 8 = 90 algorithms.

 

[xyzzy]

Perhaps @xyzzy can help with this, he's better at this kind of stuff.

lol

VOLL is not 243 algs, it is exactly 53 because it's the same step as the SOAP method's orientation stage (53 algs) but the permutation of the d-layer corners doesn't matter, meaning your second number was almost correct.

I initially thought SOAP orientation would be 56 cases, but I overcounted two cases. There are essentially seven possibilities for the D layer: solved, U, T, one twisted cw, one twisted ccw, two twisted cw, two twisted ccw. Each of these contributes eight cases for the CO on the U layer, but this would double-count the solved-U and solved-T cases, so there are really only 54 cases. The skip case doesn't need an alg, so that's 53 algs. (This is up to AUF, ADF and x2 rotation.)

VPLL is probably not that large if I'm counting it right:

D solved: 3 cases
DFR-DRB swap: 3 cases
U corner in DFR: 6 cases (same as U corner in DRB up to rotation)
U corner in DFR, DFR in DRB: 6 cases
U corner in DRB, DRB in DFR: 6 cases
Adjacent colours on DR: 6 cases
Headlights on DR: 6 cases
Opposite colours on DR: 6 cases

42 cases, one of which is a skip. This is assuming the first step is actually forming a block (half a layer), and not just a bar (half a face).

 

[bobthegiraffemonkey]

I've had a feeling for quite a while that 223+F2L pair -> stuff has potential to be nice, not really sure why though. Never looked into it, but I randomly had a fun (almost certainly bad) idea for it yesterday, posting in case it gives someone a good idea.

1) 223 + F2L pair (blockbuilding, which I'm bad at)
2) EO + remaining F2L edges
3) Insert last F2L corner and force a nice ZBLL (oriented/T/L/U I guess?)
4) ZBLL

In theory, if you can get step 2 to end <M,U>, you have great lookahead into last two steps, and you can start recognising ZBLL during step 3. It's a very rough idea and it would probably have to try to avoid bad cases for step 3 somehow, but maybe there's some potential.

Spoiler: Rough example solves

F2 L2 R2 D' R2 B2 L2 U F2 D B' R2 U R B2 U' L2 F2 U' B

z2 D2 R' U2 L' y' L U L'
R2' U R U' R' U' R
U' F' U2 L' U' L
U' R' F R F' M' U M
U D R D R' U2 R D' R' D'
U R U L' R' U2 R U M' x' z R U' R U R'


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

y D' L' U R' D' L
R2 u U2 R U' R' D'
y R' F2 R F
U r U' r' U F R' F' R2 U' R'
D R D R' U' R D' R' D'
U' F R U R' U' R' F' R U2 R U2' R' U


U2 F L2 R2 F D2 B L2 U2 B' L2 D L R2 F' L B2 D F2 U2

z2 D' F' R' U R' U' R'
y U2 R y R' U' R
L' U' L
r U' r' U F' L' U2 L F
U D R D R' U R D' R' u'
R U R' U' R' F R2 U' R' U' R U R' F'

 

[Thermex]

I initially thought SOAP orientation would be 56 cases, but I overcounted two cases. There are essentially seven possibilities for the D layer: solved, U, T, one twisted cw, one twisted ccw, two twisted cw, two twisted ccw. Each of these contributes eight cases for the CO on the U layer, but this would double-count the solved-U and solved-T cases, so there are really only 54 cases. The skip case doesn't need an alg, so that's 53 algs. (This is up to AUF, ADF and x2 rotation.)

VPLL is probably not that large if I'm counting it right:

D solved: 3 cases
DFR-DRB swap: 3 cases
U corner in DFR: 6 cases (same as U corner in DRB up to rotation)
U corner in DFR, DFR in DRB: 6 cases
U corner in DRB, DRB in DFR: 6 cases
Adjacent colours on DR: 6 cases
Headlights on DR: 6 cases
Opposite colours on DR: 6 cases

42 cases, one of which is a skip. This is assuming the first step is actually forming a block (half a layer), and not just a bar (half a face).

Yeah I was thinking some of the exact same numbers, my estimate for the permutation was really close to what you provided. I actually think I might start generating algs for this method since it's sub-100 algs and the algs would be really short. And yes, the first step is forming half a LAYER. If anyone wants to work on this with me tell me, I would do it all by myself but I'm SUPER busy with TEG and exams rn.

 

[xyzzy]

Yeah I was thinking some of the exact same numbers, my estimate for the permutation was really close to what you provided. I actually think I might start generating algs for this method since it's sub-100 algs and the algs would be really short.

Actually, I missed this earlier because I wasn't paying too much attention.

VOLL has more cases than SOAP's orientation step, because for VOLL, the solved-U and U-solved cases are distinct, as are the solved-T and T-solved cases. Furthermore, for the one-corner-twisted cases, it matters whether the twisted corner is in the front or the back. In total, there should be 72 cases (71 algs) for VOLL.

 

[Thermex]

Actually, I missed this earlier because I wasn't paying too much attention.

VOLL has more cases than SOAP's orientation step, because for VOLL, the solved-U and U-solved cases are distinct, as are the solved-T and T-solved cases. Furthermore, for the one-corner-twisted cases, it matters whether the twisted corner is in the front or the back. In total, there should be 72 cases (71 algs) for VOLL.

Lol could you reword that so it makes sense....

 

[xyzzy]

Lol could you reword that so it makes sense....

1. D oriented (8 cases, one of which is a skip)
   
2. DFR twisted cw (8 cases)
3. DFR twisted ccw (8 cases)
4. DRB twisted cw (8 cases)
5. DRB twisted ccw (8 cases)
6. DFR, DRB twisted cw (8 cases)
7. DFR, DRB twisted ccw (8 cases)
8. DFR cw, DRB ccw (8 cases)
9. DFR ccw, DRB cw (8 cases)

With SOAP, #2 and #4 collapse into a single category, as do #3 and #5, because you're free to ADF the misoriented corner wherever. This is not the case with VOLL, because you have a block that defines a fixed reference. So that's a total of 72 cases.

 

[Thermex]

@xyzzy Okay I see what you mean, I actually thought about that before but forgot you would need differemt algorithms to preserve the DRB corner so I thought you could just use a y rotation. But now that I think about it, couldn't you drastically limit the number of algs in the method with ARFs? Since you can lookahead to your VOLL case without any effort during inspection, if you got one of those back-corner-twisted front-corner-solved cases you could just do an ARF to avoid learning like 18 not-2-gen algorithms.

 

[Sue Doenim]

Roux and Screw (square 1) variant:
1) Cubeshape (obviously, parity simultaneously would be better)
2) First block
3) Solve second block, but leave it on left of U-layer
4) Solve CP and connect DB to it's corresponding spot on either block: use one of 6 algs to permute corners; DB can be simultaneously placed by using 1 moves to offset blocks, similar to how EP is influenced during CP in Vandenburg
5) Place second block while flipping equator to it's correct orientation: just insert block with either (6,0)/ or /(6,0)/ to flip equator correctly
6) (Parity) L5E: 16 cases including EPLL, 32 with parity if not finished (I think), make sure algs don't flip equator
Looks pretty nice. I don't think step 4 is infallible if done the way I explained it.

Spoiler: Step 4 algs

I'll just use 2x2 pictures for the cases

Skip

(3,0)/(3,-3)/(3,0)/(-3,0)/(0,3)/(-3,0)/

(0,-3)/(3,-3)/(0,-3)/(0,3)/(-3,0)/(0,3)/

(3,-3)/(-3,0)/(3,3)/(0,-3)/(-3,3)

NOTE: you MUST offest the algorithm by (1,0) OR (0,-1) before execution or cubeshape will be messed up
(3,-3)/(3,0)/(0,-3)/(0,3)/(0,-3)/(3,0)/(6,0)

Same rule as above applies
U D R2 D R2 U' R2 U R2 U' R2 D R2 D2
(3,3)/(0,3)/(-3,0)/(3,0),(-3,0)/(0,3)/(0,6)

I don't have L5E algs.

ZZ variant:
1) EOline
2) ZZF2L, but ignore cross pieces
3) COLL
4) y rotation, L6E
This was kind of a random bad idea until I started writing it, got to step 4, and realized it could be done as L6E instead of an <R,U,L> EPLL style algorithm. Now, it has the potential to compete with ZZ-VH, maybe even better methods.
Example solve:
Scramble: D2 R2 F2 R2 U2 B2 D' F2 U' R2 B U' B' L U B' U2 R2 U2 F
EOline: x2 D2 L' U L B D R D
ZZF2L: R2 U R2 U2 R' U2 L' U L' U2 L U2 L' U' L U' L' U' L R U R' U R U' R' U R
COLL: U' R2 D' R U R' D R U R U' R' U' R
L6E: y M' U2 M U M2 U M2 U'

 

[Thermex]

@Sue Doenim I had the exact same idea for that ZZ variant, the problem with it is that when you do the y rotation the pre-oriented good edges all become bad edges. Lol I've never solved a square-1 before but your method sounds pretty interesting. Once I learn how to solve one I think I'll look into to some Roux n Screw variants as its pretty much impossible to optimize anything in the Lars Vandenbergh method.

 

[Teoidus]

It should be alright actually since E slice edges are solved, so the y rotation won't change any orientations. However I'm not sure it's worth it

 

[Neuro]

Honestly I think that a modified Lin method would be better. Something like this:

Cubeshape
FB
SB
1 D layer edge +CP (algs exist via current Lin method but can now be more efficient due to not having to preserve a dedge)
L5E

The proposed ZZ variant *may* be better if you force either both cross pieces, ULUR, or UFUB edges into the cross slots so you can move directly into 4C. You'd have to be pretty skilled at recognizing multiple F2L possibilities though. You may be better off doing this with a modified EO line where DFDB, ULUR, or UFUB are put in the line so there's no need for rotations and F2L recog is easier

 

[Sue Doenim]

Honestly I think that a modified Lin method would be better. Something like this:

Cubeshape
FB
SB
1 D layer edge +CP (algs exist via current Lin method but can now be more efficient due to not having to preserve a dedge)
L5E

I feel like they'd be about the same. The main difference is pretty much the skipping of equator orientation. However, including that with solution of D-layer edge and corners would probably be easier and worth the 6 extra algs.

 

[Teoidus]

I also wonder if something could be done to force an easy L6EP case during CP. For example, if you could solve CP + place all opposite edges opposite of each other (kind of like phasing but for all 6 remaining edges), then the solution should be entirely intuitive + 1 parity alg if you didn't use cubeshape parity

 

[AlphaSheep]

@Sue Doenim I had the exact same idea for that ZZ variant, the problem with it is that when you do the y rotation the pre-oriented good edges all become bad edges.

No they don't. After you've solved all of the F2L edges, y rotations don't affect orientation. This method is actually OK most of the time as long as you make sure you don't trap other F2L edges under the pairs. If you do, it's a pain to have to pull them out.

 

[Thermex]

No they don't. After you've solved all of the F2L edges, y rotations don't affect orientation. This method is actually OK most of the time as long as you make sure you don't trap other F2L edges under the pairs. If you do, it's a pain to have to pull them out.

Yeah I can't believe I didn't realize that whoops

 

[Neuro]

What's the highest possible required movecount for a cross, FB, or a 2x2x2 block? Can be done with full color neutrality, but I'm trying to gauge statistics of pieces solved in comparison to # of moves performed.

 

[Teoidus]

I believe God's number for nonCN FB is 9

 

[Neuro]

I'd expect that God's number for CN FB would be 7 or 8? And I seem to remember God's number for CN cross being 7 moves. No idea about the 2x2x2 though :/