The New Method / Substep / Concept Idea Thread

[ProStar]

OCLL/PLL is 28 algs and is faster than COLL/EPLL for TH. Anyway, I still think that normal F2L would be faster.

What about for OH?

 

[Sub1Hour]

What about for OH?

Just use YruRU

 

[brododragon]

Ok, similar to my last proposal, but more of a Band type of thing.
1. EOHoop - Just a vertical EO band.
2. F4C - solve First Layer Corners.
3. L4E - Solve the E-Slice Edges.
4. COLL - Nothing special.

Also, for a higher alg-count (~200-300), you can combine 3 and 4. Can someone do the math on the number of cases?

 

[Username: Username:]

Ok, similar to my last proposal, but more of a Band type of thing.
1. EOHoop - Just a vertical EO band.
2. F4C - solve First Layer Corners.
3. L4E - Solve the E-Slice Edges.
4. COLL - Nothing special.

Also, for a higher alg-count (~200-300), you can combine 3 and 4. Can someone do the math on the number of cases?

@xyzzy

I have no idea what exactly each step is supposed to be doing, so no.

Solve E-slice edges? From where? Which edges are already solved? Are DL and DR solved??

oh well

for your requested information, please press @brododragon until spaghetti beeps

 

[xyzzy]

@xyzzy

I have no idea what exactly each step is supposed to be doing, so no.

Solve E-slice edges? From where? Which edges are already solved? Are DL and DR solved??

 

[RedstoneTim]

What about for OH?

For OH, COLL + EPLL is generally regarded as faster by pretty much all top OH solvers because of the 2-gen finish. For a more thorough explanation, have a look at Antoine Cantin's video about the topic.

Ok, similar to my last proposal, but more of a Band type of thing.
1. EOHoop - Just a vertical EO band.
2. F4C - solve First Layer Corners.
3. L4E - Solve the E-Slice Edges.
4. COLL - Nothing special.

Also, for a higher alg-count (~200-300), you can combine 3 and 4. Can someone do the math on the number of cases?

If EOHoop is orienting all the edges and permuting all U and D layer edges:

• EOHoop would be very hard to inspect, probably comparable to XEOCross.
• If you're solving the first four corners with commutators, the movecount would just be way too high.
• While L4E would be very fast (it's basically 4c but offset by a z rotation), <E, R>-gen is (in my opinion) worse than Roux's <M, U>-gen.
• The last step should be L4C, which has twice as many algorithms as COLL (84).
• Not sure about this, but algorithm count for combining the last two steps would probably be a bit higher than for ZBLL.

 

[brododragon]

Ok my last idea was pretty bad (used L4C, had no real way to solve F4C, and never solved S-slice edges). I just had a brainwave and I'd thought I could jot it down before going to bed.

1. EOBelt
2. Sort Corners
3. ZBLL
(rotate)
4. ZBLL

There could be parity, in which there are two impossible ZBLLs, but a simple alg (E-Perm would be perfect because you can easily predict ZBLL, and don't have to rotate because E-Perm starts with x) would fix it up.

Spoiler: Pros

• Very algorithmic, so it's easy to reach full move-count potential quickly.
• Algorithmic methods have higher TPS.
• Only one alg set is used.

Spoiler: Cons

• High alg-count (493), so hard to learn. You could just learn COLL/EPLL (or OCLL/PLL), but since you have to use that twice, your move-count is significantly higher.
• EOBand is very hard.
• Unavoidable rotation.

Also, you could do Band + Sort Corners, then EO. This would be significantly easier, and then you can use slice moves for EO.

 

[Cubingcubecuber]

S-slice corners

Think about this

 

[brododragon]

Think about this

Edited lol.

 

[RedstoneTim]

Ok my last idea was pretty bad (used L4C, had no real way to solve F4C, and never solved S-slice corners). I just had a brainwave and I'd thought I could jot it down before going to bed.

1. EOBand
2. Sort Corners
3. ZBLL
(rotate)
4. ZBLL

There could be parity, in which there are two impossible ZBLLs, but a simple alg (E-Perm would be perfect because you can easily predict ZBLL, and don't have to rotate because E-Perm starts with x) would fix it up.

Spoiler: Pros

• Very algorithmic, so it's easy to reach full move-count potential quickly.
• Algorithmic methods have higher TPS.
• Only one alg set is used.

Spoiler: Cons

• High alg-count (493), so hard to learn. You could just learn COLL/EPLL (or OCLL/PLL), but since you have to use that twice, your move-count is significantly higher.
• EOBand is very hard.
• Unavoidable rotation.

Also, you could do Band + Sort Corners, then EO. This would be significantly easier, and then you can use slice moves for EO.

I'll try to go through all steps and give my opinions on them:

• EOBand (maybe EOBelt?) seems to be way better than EOHoop because it only permutes four edges, probably somewhere in the EOCross region regarding difficulty.
• Sorting corners is ergonomic because of <U, D, R2>-gen, but lookahead is hindered because corners are on top and bottom and, most importantly, unoriented.
• Instead of E perm, you can also just use the standard Belt method parity alg M2 U2 M2 U2 which does a two swap of edges on both sides, so ZBLL doesn't need to be recoged three times.
• ZBLL is a bad choice here because of recognition. For some solvers who know full ZBLL, recognition can sometimes take up to a second if not more, so one would have to spend about two seconds just for recog here. Another issue is also parity. Most people either use blocks or recognition from two sides (probably fixed orientation), but not all sides, to recog the algorithms, so performing the wrong algorithm or long pauses would be very common.

 

[brododragon]

I'll try to go through all steps and give my opinions on them:

• EOBand (maybe EOBelt?) seems to be way better than EOHoop because it only permutes four edges, probably somewhere in the EOCross region regarding difficulty.
• Sorting corners is ergonomic because of <U, D, R2>-gen, but lookahead is hindered because corners are on top and bottom and, most importantly, unoriented.
• Instead of E perm, you can also just use the standard Belt method parity alg M2 U2 M2 U2 which does a two swap of edges on both sides, so ZBLL doesn't need to be recoged three times.
• ZBLL is a bad choice here because of recognition. For some solvers who know full ZBLL, recognition can sometimes take up to a second if not more, so one would have to spend about two seconds just for recog here. Another issue is also parity. Most people either use blocks or recognition from two sides (probably fixed orientation), but not all sides, to recog the algorithms, so performing the wrong algorithm or long pauses would be very common.

Could you recog parity, then, just imagine the two edges swapped and recall it while doing parity? This could drop recog times by a bit. Also, I don't know if this is feasible because I don't know ZBLL recognition, but, like you predict PLL during OLL, could you predict ZBLL or maybe just start recognizing it based off your prediction? This might (and probably is) unreasonable, but I just want to throw it out there.

Also, yes, I meant Belt, just wrote that at 12:00 AM.

 

[RedstoneTim]

Could you recog parity, then, just imagine the two edges swapped and recall it while doing parity? This could drop recog times by a bit. Also, I don't know if this is feasible because I don't know ZBLL recognition, but, like you predict PLL during OLL, could you predict ZBLL or maybe just start recognizing it based off your prediction? This might (and probably is) unreasonable, but I just want to throw it out there.

Also, yes, I meant Belt, just wrote that at 12:00 AM.

I don't know ZBLL recognition myself, but I've heard that there are two main ways to recognize it after recognizing the coll: either find patterns/blocks or choose a reference corner and recognize the edge cycle.
If one were to use the former, the whole system would probably break with parity since there are lots of cases, so it might take a while to realize that you have parity and that you're not recognizing incorrectly.
With the latter, one can recognize parity. That, however, makes the recognition three-sided instead of two-sided, so the solver needs to know which third edge means parity and which one doesn't, which adds another layer of complexity.
There's also another way to recognize which would make seeing parity a lot easier. That is recognizing OCLL/COLL and then flipping the corners in your head and recognize the PLL case. Here, parity recog would be the same as for PLL parity on 4x4 (which would still require three sides though).

So theoretically it is possible to recall during parity, but that still doesn't make your recall time faster. (That's similar to saying that recognizing and recalling PLL during PLL parity on 4x4 makes your PLL faster, which it doesn't.) That means that you still have those two seconds (or how long it takes two recog and recall ZBLL times two) and the rotation added to your solving time.
(Also I hope you're fully awake by 12 AM, lol)

 

[brododragon]

So theoretically it is possible to recall during parity, but that still doesn't make your recall time faster. (That's similar to saying that recognizing and recalling PLL during PLL parity on 4x4 makes your PLL faster, which it doesn't.) That means that you still have those two seconds (or how long it takes two recog and recall ZBLL times two) and the rotation added to your solving time.
(Also I hope you're fully awake by 12 AM, lol)

How does doing recog during the parity alg not make the rest shorter? Instead of having 2 seconds where you don't turn, you'll have 1.25 (2 minus parity execution) seconds where you don't turn.

 

[RedstoneTim]

How does doing recog during the parity alg not make the rest shorter? Instead of having 2 seconds where you don't turn, you'll have 1.25 (2 minus parity execution) seconds where you don't turn.

I think I worded that badly.
My point is that you have 2 seconds or so added to your solve because of ZBLL recog and recall.
When there is parity, you still need those 2 seconds to recog and recall, but in the mean time you're also executing the parity alg. That means that in optimal circumstances, a solve with parity would be as fast as a solve without it. That doesn't mean, however, that getting parity makes your whole solve faster than if you didn't get it.
And therefore, your method still has those 2 seconds added because of ZBLL, which means that another variant with better recog and recall but longer algs/more steps might be better if recog + recall + execution of it would be faster than that of ZBLL.

 

[brododragon]

I think I worded that badly.
My point is that you have 2 seconds or so added to your solve because of ZBLL recog and recall.
When there is parity, you still need those 2 seconds to recog and recall, but in the mean time you're also executing the parity alg. That means that in optimal circumstances, a solve with parity would be as fast as a solve without it. That doesn't mean, however, that getting parity makes your whole solve faster than if you didn't get it.
And therefore, your method still has those 2 seconds added because of ZBLL, which means that another variant with better recog and recall but longer algs/more steps might be better if recog + recall + execution of it would be faster than that of ZBLL.

Ok. So, do you think OCLL/PLL or COLL/EPLL could be faster? I think something like this that's 3-look could be just as fast/faster.
1. COLL
2. (rotate) COLL
3. Parity
4. PBLE (Permute both layer edges)

This would keep down on alg count, allow for PBLE recognition during parity, and make parity easy to recog. The reason I would choose this over OCLL/PLL x2 is that that is 4-Look.

 

[RedstoneTim]

Ok. So, do you think OCLL/PLL or COLL/EPLL could be faster? I think something like this that's 3-look could be just as fast/faster.
1. COLL
2. (rotate) COLL
3. Parity
4. PBLE (Permute both layer edges)

This would keep down on alg count, allow for PBLE recognition during parity, and make parity easy to recog. The reason I would choose this over OCLL/PLL x2 is that that is 4-Look.

That seems better, though maybe there's a way to do both COLL algorithms rotationlessly? (Like CO on both sides + CP on both sides, but that would probably be a worse variant of SSC.)
Also do you know how many algorithms PBLE is? (Since I've heard that it's a lot for Square-1 and the number of algs is probably similar.)

 

[WarriorCatCuber]

All right, I'm trying to find a viable waterman variant with EO at the beginning.
1. EOFirstLayerMinusOneEdge
2. COLL
3. Do z so the empty first layer edge is a at LU, then Solve the BR, DR and BD edges, as well as the M centers
4. Finish the cube using L6EP

 

[brododragon]

That seems better, though maybe there's a way to do both COLL algorithms rotationlessly? (Like CO on both sides + CP on both sides, but that would probably be a worse variant of SSC.)

People can mirror an alg on the fly, so I wonder if with a little training you could flip an alg upside down.

Also do you know how many algorithms PBLE is? (Since I've heard that it's a lot for Square-1 and the number of algs is probably similar.)

Woah. My math has gotta be off. It's 20,160, according to my (almost certainly wrong) calculations. 8! (Number of edges) / 2 (permutation parity) = 20,160. I guess you could solve DL and DR for intuitive L6EP. This would help with the rest of the solve, as you wouldn't need to solve F and B centers to for EOBand.

 

[Devagio]

This thread is based off the idea of CP-line as found here:

Roux-breaker? The YruRU method

Inspecting CP in inspection allows us to solve the entire cube 2-gen. Many cubers, notably Jayden and Bhargav are particularly excited by this idea; and this can potentially beat Roux for One-handed solving. If you find it game-changing, or otherwise, let me know. I'll be putting this up along...

www.speedsolving.com

While the YruRU method has great potential in theory, by far its biggest drawback is doing EO of 9 edges midsolve (compared to 6 in Roux), which may not be very TPS friendly.
The idea here is to eliminate this, albeit at the cost of giving up RU turning for MU turning and trading an RU algset for an rRU algset of similar size. The movecount remains similar.
This could technically count as a variation of Roux, or a fusion of YruRU and Roux, however you prefer.

Scramble: D2 F2 R B2 D2 B2 R’ F2 L’ B2 F2 U F D L’ F’ D B’ U L2

Solution:

z y // inspection
F U’ f’ U F // CP-line (5/5)
This is identical to the first step from YruRU. This step could in general always be done as 2-gen 4-6 mover followed by a rotation (though that may not always be the fastest solution).

R' u2 U R u' // Craddle (5/10)
This is basically Roux FB with misaligned centres. Since we will be finishing with MU turning, this is can be fixed then.
An intermediate solver should be fairly consistently be able to plan the CP line and track the remaining two cradle edges.
Note that this step is quite trivial to do, which should give ample opportunity to find and track the DR edge and proceed with second block identically as in Roux.

U r' R U' R2 // square of 2nd block minus centre (5/15)
U R U2 R' // final pair (4/19)
At this point, we only need to insert the pair to finish SB; upto here generally takes ~20 moves.

We can have 3 kinds of pairs at this point, the R U R' insert, the R U' R' insert, or the r U r' insert

Now, we insert this pair using algorithm, that also orients all corners on top.
This is like winter variation/summer variation on roux, but it turns out that most of the long algorithms become much better due to the freedom of M slice and no top layer orientation to care about.
For example, the WV case solved in CFOP with [U R U2 R2 U2 R U R' U R] can be solved in roux using [U2 r U2 r' U2 R U' R']
There will be 81 algs in this set, 27 for each insert; the algset so far seems to be much faster than CMLL both in recognition (since only CO needs to be checked) and execution (rRU turns only, lower average move-count).
[I am currently generating algs for all these cases, the above statement is based off of the 27/81 algs that I have generated so far]

U' r U R2 U' R U' R' U2 r // 4-seasons(?) alg (10/29)

This alg is a decent representation of the set, and now we are left with centres and L6E. (Since CP was done initially and CO was done now, we have no CMLL of course).

Now, we can fix centres like we do in the misaligned centres version of roux; and quite often, we can force an arrow, or even EO skip. The cases are obvious to figure out on your own over time. Here, there is a straight forward way to do so as follows (Note, now we will only have M moves instead of R and r):

U u M' u' // fixed centres and forced arrow (4/33)

Now, the usual L6E follows.

Transition to this method will be very simple for Roux users.


PS. While by no means did YruRU "break" Roux yet, this title for the thread is chosen to simply go with the theme; and the funny similarity in the phonetics of the two method names.

 

[brododragon]

EO of 9 edges midsolve

Actually, it would only be 8, as at least one edge will always be pre-oriented, making it compareable to Petrus EO. Petrus EO, contrary to popular belief, isn't that hard or time consuming. You only need to find two flipped edges and then you can recognize the next two while fixing the first two, and keep repeating this.