• Welcome to the Speedsolving.com, home of the web's largest puzzle community!
    You are currently viewing our forum as a guest which gives you limited access to join discussions and access our other features.

    Registration is fast, simple and absolutely free so please, join our community of 40,000+ people from around the world today!

    If you are already a member, simply login to hide this message and begin participating in the community!

Roux-breaker? The YruRU method

PapaSmurf

Member
Joined
Jan 4, 2018
Messages
1,103
WCA
2016TUDO02
YouTube
Visit Channel
I checked out the 2GR system in depth, and I do not agree here. The many steps in the system and the lack of flexibility make it take longer to inspect, and relatively inefficient for CP-line. The system was developed to combine with EO-pair, which it does brilliantly. But as stand-alone for CP-line it gets beaten both in inspection speed and in move efficiency/flexibility. This could possibly be taken up for debate till somebody practices with both techniques; but what is certain is EO-CP-line is impossible to do consistently in 15 second inspection using the 2GR system.
Just letting you know that every system ever devised to solve CP is the same thing through a different lense, so move efficiency/flexibility isn't a thing to worry about (especially when you're ignoring EO in Briggs FB). I would also say that in your CP solving idea, you solve line, then CP, then you solve the rest of FB, which is objectively worse than solving CP with FB (which 2GR system allows for). Inspection speed can be changed though by making the lense more efficient (if that makes any sense).
 

Devagio

Member
Joined
Apr 21, 2020
Messages
266
in your CP solving idea, you solve line, then CP
Nope, CP is solved along with line. If you got this impression from first few example solves, they were done when the idea was kinda preliminary. Check out the CP-line examples on this thread.
CP line is extended into block because inspecting entire CPFB consistently doesn’t seem human for now for either YruRU’s inspection, or for 2GR’s inspection; but if one of these has a better chance of achieving that, it’ll be YruRU’s inspection.

That said, every CP solving system doesn’t do the same thing. The difference is not simply looking at things differently; in fact, 2GR’s solution of CP line and YruRU’s solution of CP line can never match unless there’s CP skip. I suggest you check out both ways of doing it in detail.
 

PapaSmurf

Member
Joined
Jan 4, 2018
Messages
1,103
WCA
2016TUDO02
YouTube
Visit Channel
Nope, CP is solved along with line. If you got this impression from first few example solves, they were done when the idea was kinda preliminary. Check out the CP-line examples on this thread.
CP line is extended into block because inspecting entire CPFB consistently doesn’t seem human for now for either YruRU’s inspection, or for 2GR’s inspection; but if one of these has a better chance of achieving that, it’ll be YruRU’s inspection.

That said, every CP solving system doesn’t do the same thing. The difference is not simply looking at things differently; in fact, 2GR’s solution of CP line and YruRU’s solution of CP line can never match unless there’s CP skip. I suggest you check out both ways of doing it in detail.
I'll give it a deeper look then.
 

y235

Member
Joined
Jan 29, 2011
Messages
334
Location
Israel
WCA
2011BROD01
YouTube
Visit Channel

Turns out Gilles Roux himself aslo thought about YRUru (but dismissed it as not good enough). I also don't know what CP recognition system he used
 

Devagio

Member
Joined
Apr 21, 2020
Messages
266
Partial edge control during FB

The development in this post marks the completion of the skeletal structure of YruRU; so now I can start working on a tutorial pdf and possibly a github page. This post addresses and I believe completely resolves the bottleneck of the EO stage; which now is considerably superior to the EO stage of any variation of LEOR, Briggs, etc. that I could find online or think of.

After forming the CP-line, the next step in YruRU is to extend it to a 1x2x3 block. This takes 6-7 moves, during which the brain is mostly idle since the step is somewhat trivial. The following step is EO, so this idle time I initially thought would best be utilised to look ahead to this step since influencing EO during this step would be somewhat difficult. However it turns out it is possible to do partial EO adding 2 moves at worst (though overall saving moves since EO will be far fewer moves), not decreasing TPS at all, immensely restricting the cases possible during EO-step, and equally improving the look ahead.

Most FB extentions are traditionally solved this way (unless you basically have 2-move setups):
1. Bring the corresponding centre on R face,
2. Attach an edge to the centre while doing so,
3. Bring the other edge to the U layer,
4. Attach the other edge to the centre and bring this entire structure to the L face to make the FB.

Steps 1 and 2 take a combined 1-3 moves to achieve. Here is where we start thinking about partial edge control. The next steps are modified as follows:
3. Bring the other edge to the U layer such that an F/B centre is on top, and the edge is either on UF or UB
4. Take a note of whether there are more good edges or bad edges while attaching the other edge
5. If the attachment is of u R u type, end the combination with r (or U2 r) if there were more good edges, or U' r (or U r) if there were more bad edges. Vice-versa if the attachment is of U R u2 (In case of more bad edges and U R u2 type attachment, simply U r u2 saves a move).

With this step, you are basically orienting at least 2 edges, possibly 3. I have done some examples at the end to help understand the cases better and actually appreciate the power of this.

Using traditional FB extension, the probabilities are as follows:
0 bad edges: 0.4%
2 bad edges: 14%
4 bad edges: 49%
6 bad edges: 33%
8 bad edges: 3.5%

Using the above mentioned partial edge control, these probabilities become:
0 bad edges: 2.0%
2 bad edges: 36%
4 bad edges: 53%
6 bad edges: 9%
8 bad edges: 0.0%

Moreover, this partial EO enables us to always put a good edge in DB, which is our blindspot. We already know the orientation of 3 of our edges (which usually all end up on the B face, and most of them are good), thus we simply need to look at the orientation of 5 more edges to determine the EO case, all 5 of which are visible.
To compare with Roux EO, we need to look at the orientation of 5 edges, all 5 of which are visible, and the probabilities here are:
0 bad edges: 3.1%
2 bad edges: 47%
4 bad edges: 47%
6 bad edges: 3.1%
[Doing partial EO in Roux is not a good idea since 4 bad edges is better than 2 bad edges for Roux, no such thing is true for YruRU]

Thus recognition-wise, this becomes comparable to Roux, and thus is no longer a bottleneck for the method, making it viable to compete with the best methods out there. Execution-wise, we reduce the average move-count substantially since we have high move counts in the EO step only if there are 6 or 8 bad edges, which reduced from ~40% to less than 10%, and only the better of the cases arise.
[Such things are not possible in LEOR, Briggs, etc. due to the way FB is made in those methods, and a much more complicated / time-consuming way of partial edge control would have to be done.]

While this seems simple, it took me quite a long time to come up with. Thanks to @PapaSmurf for making me realise more can be done during the FB extension, for absolutely no cost at all.

Here are some examples:

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

z’ y
Corners already solved
Sequence - 312
R’ (F’ u’ F) U S’ // CP-line
u r2 u r' U' // setup
At this point, the edge in UR is good, the edge in UL is bad. The edge in UF looks good, but we have to flip the orientation of the edge opposite to our orange edge due to the orientation of the centres. Thus, the edge is bad. We have two bad edges and one good edge. Thus:
u R' u // FB
U' r // Partial edge control



y R L U' F2 L' F' D B U' F D B2 U' B2 L2 D L2 F2 U2 L2 F2

z’
F // corners
Sequence - 321
r (F r F) f2 // CP-line
R' u R // setup
At this point, the edges in UL and UR are bad, so we already know what to do, but just for the sake of the example, we look at the edge in UB. It looks bad but since it is opposite to our red edge, it is actually good. Nonetheless, we have more bad edges than good edges. Thus:
U' R' u2 // FB
r // Partial edge control (Note here we didn't use the trick mentioned in the bracket, just for the sake of having a simple example)


y U2 R F2 R D2 L' B2 U2 R2 U2 L2 U' B2 L B L' R2 B2 D2 L U'

x z’
Corners already solved
Sequence - 312
r (F’ u’ F2) f’ // CP-line
r2 R' u R2 // setup
UL and UR are bad, same case as above.
U' R u2 // FB + Partial edge control (here we used the trick mentioned in the bracket)



y F2 B' D2 L F2 D2 R2 L U' F' R' F2 L D2 L' F2 U2 R' U2 D2 F2

z x’
F2 f // line
Sequence - 321
(F R F’) // CP-line
[with cancellations: z x’ S R F’]
U R U r // setup
UL and UR are bad (UF is also bad but we don't need to check it), Thus:
U R' u2 // FB
r // Partial EO (here, we didn't use the trick of the bracket to ensure a good edge ends up in DB)
Note, we have a beautiful block, which we can preserve:
r U R U r' // EO
U2 r U2 r' // BF + square


Note, the number of EO cases is so severely restricted, that we can actually memorise algorithms for each EO case. We will have around 30 short algorithms to memorise. I will generate these and put up here soon.

EDIT: Out of the 16 possible (all equiprobable) cases there are two cases where ensuring DB is good is slightly complicated. In the U’ R u2 type insert, if UR and UL are good, but the UB is bad, instead of doing U’ R u2 U’ r, do r u R’ u U r2. This is the only case not completely intuitive.
 
Last edited:

mukerflap

Member
Joined
Jan 12, 2020
Messages
261
Partial edge control during FB

The development in this post marks the completion of the skeletal structure of YruRU; so now I can start working on a tutorial pdf and possibly a github page. This post addresses and I believe completely resolves the bottleneck of the EO stage; which now is considerably superior to the EO stage of any variation of LEOR, Briggs, etc. that I could find online or think of.

After forming the CP-line, the next step in YruRU is to extend it to a 1x2x3 block. This takes 6-7 moves, during which the brain is mostly idle since the step is somewhat trivial. The following step is EO, so this idle time I initially thought would best be utilised to look ahead to this step since influencing EO during this step would be somewhat difficult. However it turns out it is possible to do partial EO adding 2 moves at worst (though overall saving moves since EO will be far fewer moves), not decreasing TPS at all, immensely restricting the cases possible during EO-step, and equally improving the look ahead.

Most FB extentions are traditionally solved this way (unless you basically have 2-move setups):
1. Bring the corresponding centre on R face,
2. Attach an edge to the centre while doing so,
3. Bring the other edge to the U layer,
4. Attach the other edge to the centre and bring this entire structure to the L face to make the FB.

Steps 1 and 2 take a combined 1-3 moves to achieve. Here is where we start thinking about partial edge control. The next steps are modified as follows:
3. Bring the other edge to the U layer such that an F/B centre is on top, and the edge is either on UF or UB
4. Take a note of whether there are more good edges or bad edges while attaching the other edge
5. If the attachment is of u R u type, end the combination with r is there were more good edges, or U' r if there were more bad edges. Vice-versa if the attachment is of U R u2 (In case of more bad edges and U R u2 type attachment, simply U r u2 saves a move).

With this step, you are basically orienting at least 2 edges, possibly 3. I have done some examples at the end to help understand the cases better and actually appreciate the power of this.

Using traditional EO extension, the probabilities are as follows:
0 bad edges: 0.4%
2 bad edges: 14%
4 bad edges: 49%
6 bad edges: 33%
8 bad edges: 3.5%

Using the above mentioned partial edge control, these probabilities become:
0 bad edges: 2.1%
2 bad edges: 38%
4 bad edges: 52%
6 bad edges: 8%
8 bad edges: 0.0%

Moreover, this partial EO enables us to always put a good edge in DB, which is our blindspot. We already know the orientation of 3 of our edges (which usually all end up on the B face, and most of them are good), thus we simply need to look at the orientation of 5 more edges to determine the EO case, all 5 of which are visible.
To compare with Roux EO, we need to look at the orientation of 5 edges, all 5 of which are visible, and the probabilities here are:
0 bad edges: 3.1%
2 bad edges: 47%
4 bad edges: 47%
6 bad edges: 3.1%
[Doing partial EO in Roux is not a good idea since 4 bad edges is better than 2 bad edges for Roux, no such thing is true for YruRU]

Thus recognition-wise, this becomes comparable to Roux, and thus is no longer a bottleneck for the method, making it viable to compete with the best methods out there. Execution-wise, we reduce the average move-count substantially since we have high move counts in the EO step only if there are 6 or 8 bad edges, which reduced from ~40% to less than 10%, and only the better of the cases arise.
[Such things are not possible in LEOR, Briggs, etc. due to the way FB is made in those methods, and a much more complicated / time-consuming way of partial edge control would have to be done.]

While this seems simple, it took me quite a long time to come up with. Thanks to @PapaSmurf for making me realise more can be done during the FB extension, for absolutely no cost at all.

Here are some examples:

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

z’ y
Corners already solved
Sequence - 312
R’ (F’ u’ F) U S’ // CP-line
u r2 u r' U' // setup
At this point, the edge in UR is good, the edge in UL is bad. The edge in UF looks good, but we have to flip the orientation of the edge opposite to our orange edge due to the orientation of the centres. Thus, the edge is bad. We have two bad edges and one good edge. Thus:
u R' u // FB
U' r // Partial edge control



y R L U' F2 L' F' D B U' F D B2 U' B2 L2 D L2 F2 U2 L2 F2

z’
F // corners
Sequence - 321
r (F r F) f2 // CP-line
R' u R // setup
At this point, the edges in UL and UR are bad, so we already know what to do, but just for the sake of the example, we look at the edge in UB. It looks bad but since it is opposite to our red edge, it is actually good. Nonetheless, we have more bad edges than good edges. Thus:
U' R' u2 // FB
r // Partial edge control (Note here we didn't use the trick mentioned in the bracket, just for the sake of having a simple example)


y U2 R F2 R D2 L' B2 U2 R2 U2 L2 U' B2 L B L' R2 B2 D2 L U'

x z’
Corners already solved
Sequence - 312
r (F’ u’ F2) f’ // CP-line
r2 R' u R2 // setup
UL and UR are bad, same case as above.
U' R u2 // FB + Partial edge control (here we used the trick mentioned in the bracket)



y F2 B' D2 L F2 D2 R2 L U' F' R' F2 L D2 L' F2 U2 R' U2 D2 F2

z x’
F2 f // line
Sequence - 321
(F R F’) // CP-line
[with cancellations: z x’ S R F’]
U R U r // setup
UL and UR are bad (UF is also bad but we don't need to check it), Thus:
U R' u2 // FB
r // Partial EO (here, we didn't use the trick of the bracket to ensure a good edge ends up in DB)
Note, we have a beautiful block, which we can preserve:
r U R U r' // EO
U2 r U2 r' // BF + square


Note, the number of EO cases is so severely restricted, that we can actually memorise algorithms for each EO case. We will have around 30 short algorithms to memorise. I will generate these and put up here soon.
R2 F2 D2 U' L2 D B2 D' L D' U2 L' F' D L' B F2 R' U'
x f r2 U2 r' F'
U R2 U R' U2 R U2 R' U2 R U R U' R' U R U R'
F R U' R' U R U2' R' U' F'
U M2 U' M' U2 M' U2 M U M2 U' M'
45 stm

R L U' F2 L' F' D B U' F D B2 U' B2 L2 D L2 F2 U2 L2 F2
z U' r' R' U S' U2 F' U F'
r U r U R' U2 R' U2 r' U r
F R U R' U' F'
M2 U M U2 M2 U' M'
33 stm

U2 R F2 R D2 L' B2 U2 R2 U2 L2 U' B2 L B L' R2 B2 D2 L U'

y' U D' R' U' R D U r' U' r F'
M2 U R2 U' R' U' R U2 R' U' R r U r'
F R U R' U' R U R' U' R U R' U' F'
U' M' U2 M' U2 M' U' M U' M' U2 M
50 stm

F2 B' D2 L F2 D2 R2 L U' F' R' F2 L D2 L' F2 U2 R' U2 D2 F2
x2 M f r D M' U2 F'
r U R' U2 R U' R' U R U R U' R' U2 r U r'
U F R U' R' U' R U R' U R U' R' F'
M2 U M U' M' U' M2 U' M2
47 stm
 

Devagio

Member
Joined
Apr 21, 2020
Messages
266
Note, the number of EO cases is so severely restricted, that we can actually memorise algorithms for each EO case. We will have around 30 short algorithms to memorise. I will generate these and put up here soon.
The idea to do EO is, as soon as the FB+partialEO is done, intuit the number of bad edges present on the cube. Since all bad edges will be in the field of view, the accuracy of doing this will be near perfect given the small discrete set {0 (2%), 2 (36%), 4 (53%), 6 (9%)}. Then, identify the case and do the algorithm. The recognition speed should be comparable to OLL. Here is an exhaustive list of cases to be memorised. All these are completely intuitive, and it should not take more than one session to memorise them all.

Note, the last two moves are in bold since they can be any one of U r, U' r, U r', U' r'


2 bad edges:

DF is bad: set up the other edge to one of these positions:
UR: r U' R' U r
RD: r U' R U r
RB: r U' R2 U r

DF is good, both bad edges in U layer:
UF-UB: r U' r U' R' U r
UF-UR: r U R' U r (mirror for UB-UR)

DF is good, one bad edge in U layer:
UF-RD: r U R U r (mirror for UB-RD)
UF-RB: r U R2 U r (mirror for UB-RF)
UF-RF: R' r U R U r (mirror for UB-RB)

If DF is good and both bad edges are in R layer: bring one of them to UF/UB:
RB-RD: R' U r U R2 U r (mirror for RD-RF)
RF-RB: R U r U R U r

All other cases' optimal solutions are 1 move setups to these (i.e. using R/U moves).


4 bad edges:

DF is bad: all (except one special case) optimal solutions are 0-3 move setups to staircase (UL-UF-RF) [or to arrow (UL-UF-UR) which basically sets up to staircase]:
Staircase: r U r
Arrow: R' r U r
UF-UL-RD: R r U r
UF-UL-RB: R2 r U r
UF-UB-RF: R U R' r U r
UF-UB-RD: R2 U R' r U r
UF-UB-RB: R' U R' r U r
UF-RF-RD: R U r U r
UF-RB-RD: R2 U r U r
RF-RB-RD: R U R U r U r
Special case - UF-RF-RB: r U2 R2 U r

DF is good: make DF/DB bad using r U2 r or r2, then convert to staircase (or arrow)
UF-UR-UB-UL: r U2 r' U2 r U r
UF-UB-RF-RB: r U2 r U' r U r
UF-UB-RB-RD: r U2 r U2 r U r (mirror for UF-UB-RF-RD)
UF-UR-RF-RD: r2 U' R' U' r' U r (mirror for UB-UR-RB-RD)
UF-UL-RF-RB: r2 U r U2 r2 U r
UF-RF-RD-RB: r2 U' r U2 r2 U r
UF-UR-UB-RF: r U' r' U2 r U r (mirror for UF-UR-UB-RB)
UF-UR-UB-RD: R r U2 r U' r U r

All other cases' optimal (or 1 move over optimal) solutions are 1 move setups to these (i.e. using R-U moves)


6 bad edges:

DF is good: Put the only other good edge in UR and do: r U2 r U' r' U' r2 U r

DF is bad: simply put the two good edges in UR and DR using <R, U> moves, and do r' U' r2 U r
Here, I will denote the case using good edges instead of bad edges:

Both good edges in U layer:
UF-UR: R2 U' r' U' r2 U r
UL-UR: R2 U2 r' U' r2 U r

One good edge in U layer:
UF-RF: R' U' r' U' r2 U r (mirror for UB-RB)
UF-RD: U' r' U' r2 U r

Both good edges in R layer:
RF-RB: R r' U' r2 U r
RF-RD: R U R' U' r' U' r2 U r (mirror for RB-RD)
 
Last edited:

Devagio

Member
Joined
Apr 21, 2020
Messages
266
This is awesome, but how do you do it if you have a U r u2 case? There's no U move to manipulate before the r move.
You do U R u2 r instead, if U r u2 doesn’t put an oriented edge in. The trick in the bracket doesn’t work very often, which is why I put it in a bracket (it works in 75% of the cases)
On this thread the stuff I put in brackets is generally things I find interesting but that may not be objectively good to implement.
 
Last edited:

Devagio

Member
Joined
Apr 21, 2020
Messages
266
I would totally do this but the concept of CP is really wierd for me
Now that the primary developmental phase for the method is done, I’ll ask some YouTubers to make CP tutorials, they’ll definitely do a better job than me. If there are some reading this thread and have been able to make sense of it, they can perhaps give it a spin.
Stick with it though, it’s really not that hard. There’s nothing to understand, just a couple of rules you have to mug up.
 

PapaSmurf

Member
Joined
Jan 4, 2018
Messages
1,103
WCA
2016TUDO02
YouTube
Visit Channel
I'm still confused to why this is anything different to Briggs. It's literally exatly the same, so if you do get youtubers to make a tutorial, call it Briggs, not YruRU. Also, 2GR CP is better IMO because you don't need to solve the second corner before CP AND you can actually do CPFB which is definitely possible in inspection. If it isn't, then this method automatically loses out to Roux because you can see all of FB and some of SB in inspection consistently. It also loses out to LEOR because you are doing extra work for something that makes EODFDB and RB harder (lack of D and F moves). If you're still confident that doing CP has any speed benefit, work out if your 2GLL algs are any faster than ZBLL algs. because the time save at best will be about .2 seconds on average for worse lookahead.
 
Joined
Jun 21, 2015
Messages
12
Location
Hong Kong
WCA
2017TUNG13
YouTube
Visit Channel
you don't say you're method neutral if you know two different ways to recognize like some coll case or something, and the same thing applies here

it's another way (potentially better?) to recognize cp, but that's like using a 3sticker 2 face cmll recognition system compared to a 5sticker 4face cmll recognition system or something - it's still the same thing

(although like i don't believe that inspection is that much better anyway, but an example is an example)
 

Devagio

Member
Joined
Apr 21, 2020
Messages
266
Advances in Inspection

Let me first talk about an obvious advanced version of the YruRU recognition system.
Assume that the DL corners are solved, like in this scramble: R2 F2 D2 U' L2 D B2 D' L D' U2 L' F' D L' B F2 R' U' z' y
According to the beginner YruRU approach, after spotting corners 5 and 6, we need to mentally swap pieces and trace accordingly. However, with little time, it becomes obvious that there are only 30 possible configurations of corners 5 and 6; so we can simply memorise a trace circlet in each case (14 of these 30 cases are trivial since 5 and 6 are friends or almost friends in these cases). In this case, 5 is in UFL and 6 is in DBR, so the circlet is UBL>UFR>UBR>DFR>UBL. Now, while we can start our tracing now, there's a further obvious simplification; at this point, look for corner 4. In this case, it is in UBL. Now, we just need to trace the two corners in the circlet after 4; i.e. we only need to look at UFR>UBR. In this case, it is 3>1; thus this is the case known in beginners' tracing as 312.

Now, again assuming that the DL corners are solved, here is why this tracing is objectively (much) faster than 2GR tracing-

2GR tracing steps:
A. Find 5 & 6, decide where they are in relation to each other.
B. Recall which corners to trace.
C. Trace, getting three numbers.
D. Figure out the sequencing (like jump, forward or backwards, backwards).
E. Decide swap.

YruRU tracing steps:
a. Find 5 & 6, decide where they are in relation to each other.
b. Recall the circlet.
c. Find 4.
d. Trace, getting 2 numbers
e. Decide swap

Note that A=a and E=e; b is the same as B, d is faster than C (since 2 is less than 3), c is faster than D (since c involves spotting, D involves calculating). Moreover, b and c can be done in parallel, while no such parallel processing is possible in the 2GR system.

Also, in the case that DL corners are solved, YruRU allows for 3 possible swaps while 2GR allows for only 1, so CP-line move count is going to be much lesser for YruRU (Difference of around 1.5 STM on average, that is around 30% of the average CP-line movecount; which also leads further planning issues).


Now, to talk about cases where DL corners are not solved (roughly half of the scrambles for x2 y neutrality, and three quarters of the scrambles for x2 y2 neutrality).
While 2GR doesn't allow for very flexible solutions (due to only one swap instead of a choice from 3 swaps, thus leading to inefficient CP-line since cancellations will rarely occur), inspection wise, it is a better option (objectively better when it is 2 moves to solved corners, which is roughly 10% of scrambles in x2 y neutrality, 25% of scrambles in x2 y2 neutrality).

Thus, here I will outline 2GR's way of handling the case where DL corners are not solved (modified such that YruRU users can use it best):

i. Assume that the corner to be solved in DFL is actually the corner currently present in DFL
ii. Find 5 & 6, decide where they are in relation to each other.
iii. Recall the circlet.
iv. Find 4.
v. Trace, getting 2 numbers.
vi. Decide swap such that it involves the DFL corner.

Now, to solve the CP case, use <R, U> moves so that the DFL corner is either an F or an F' away from being solved, and the corner to be swapped with it is in UBR. Then, do the F or F' to solve CP. Use wide move wherever required to better place the DL edge.


Special Case: If DL corners are not solved and we get the solved CP case (i.e. there is no corner to put in UBR or in different words, the beginner tracing gives sequence 123)-
I am not sure if this is the best way to do this, but here is what I figured -
Use <R, U> moves so that the DFL corner is either an F or an F' away from being solved. Then, do the F R F R F' or F' U' F' U' F respectively. Use wide move wherever required to better place the DL edge. This is 2gen, so you can make it an <R, U> trigger followed by a rotation.
If someone comes up with a better idea I'll add it here; I'm certain there is a better way to do this.
Edit: Found a better way of handling this; mentioned it on page 11 of this thread.

Nightmare Case: Roughly once in every 2000 scrambles, there will be a case for x2 y2 neutral solvers where all DL corner pairs are relatively twisted while in correct permutation. Since this is so rare, it is wise to take a DNF (or just use CFOP, etc.) instead of memorising a special way to handle this.


Example: F2 B' D2 L F2 D2 R2 L U' F' R' F2 L D2 L' F2 U2 R' U2 D2 F2

We will solve red on left white on bottom.
i. Since 5 is in DFL, the white-green-red corner (currently in UFL) is 5.
ii. 5 is in UFL, 6 is in DFR.
iii. Circlet is UFR>UBL>UBR>DBR>UFR
iv. 4 is in UBL.
v. UBR is 1, DBR is 3.
vi. 5 swaps with 4.

U' R' U2 (this puts the DFL corner an F away from being solved, and puts 4 in UBR)
F // solves CP
U S2 // solves line
(While this looks slightly inefficient, the extra inspection time and there being a single F move in the entire solve makes it a worthwhile trade in my opinion.)

I intended to post this earlier, but I simply wanted to be sure of my claims and numbers, so I took two days to experiment with this idea.
 
Last edited:

Athefre

Member
Joined
Jul 25, 2006
Messages
1,248
Sometimes ideas aren't good, sometimes an idea has already been proposed and a small change isn't going to make it a completely new method, sometimes both. You have to be able to recognize that. It's important to be respectful to the work that others have put into things. Several people have already provided important points to consider. If your goal is to ignore this advice, then you aren't going to be respected by the community.
 

Cuberstache

Member
Joined
May 7, 2018
Messages
1,042
Location
Washington State, USA
WCA
2016DAVI02
YouTube
Visit Channel
we can simply memorise a trace circlet in each case (14 of these 30 cases are trivial since 5 and 6 are friends or almost friends in these cases).
This is awesome; I'm currently working out the non-trivial cases. What do you mean by "almost friends"? There are 6 cases where they're friends, so what are the 8 cases where they're almost friends?
 

PapaSmurf

Member
Joined
Jan 4, 2018
Messages
1,103
WCA
2016TUDO02
YouTube
Visit Channel
There's little to no point saying how to treat the case where the DL corners are solved. 2GR isn't especially designed to solve that case, so doing a short alg to solve CP is a lot simpler, although C and D are done in exactly the same step.
For the modified version, itis just 2GR style, so you are doing the same thing through a different lense. The example of CMLL recog is a good one. Both ways recog and solve CP but they're 2 different sides of the same coin and best. Otherwise they're like venn diagrams that overlap almost completely. The biggest advantage of 2GR. is that it allows you to trace CP through FB, which is definitely the best route to go down in the long run, which your method(currently) doesn't have, except that it does, because it is the same as 2GR. As Athefre said, this is definitely not new and I think you need to recognise that. If you're trying to opimise Briggs, do it, I encourage you, but if you're trying to push 'your new YruRU method that's going to change the cubing meta', stop. Because very simply, it's not yours and it's not new.
 

Devagio

Member
Joined
Apr 21, 2020
Messages
266
This is awesome; I'm currently working out the non-trivial cases. What do you mean by "almost friends"? There are 6 cases where they're friends, so what are the 8 cases where they're almost friends?
If 5 is in UFL and 6 is in UFR, then simply doing a U will make them friends (with 5 on even) so the circlet will simply become DBR>DFR>UBR>UBL>DBR. Sort of a trick I used when I did beginner tracing.

For the modified version, itis just 2GR style, so you are doing the same thing through a different lense.
Yes, and I mentioned that.


There's little to no point saying how to treat the case where the DL corners are solved. 2GR isn't especially designed to solve that case, so doing a short alg to solve CP is a lot simpler, although C and D are done in exactly the same step.
For the modified version, itis just 2GR style, so you are doing the same thing through a different lense. The example of CMLL recog is a good one. Both ways recog and solve CP but they're 2 different sides of the same coin and best. Otherwise they're like venn diagrams that overlap almost completely. The biggest advantage of 2GR. is that it allows you to trace CP through FB, which is definitely the best route to go down in the long run, which your method(currently) doesn't have, except that it does, because it is the same as 2GR. As Athefre said, this is definitely not new and I think you need to recognise that. If you're trying to opimise Briggs, do it, I encourage you, but if you're trying to push 'your new YruRU method that's going to change the cubing meta', stop. Because very simply, it's not yours and it's not new.
I by no means intend to disrespect or belittle the work and analysis done by others, or take credit for things not originally mine. If somebody wants to consider YruRU a variation of Briggs, or simply want my name out of it, go ahead; you would be well justified due to the overwhelming similarity it bore with Briggs, especially when I first put it out.
I was excited when I came across an idea, and I’m here to defend and develop it, not necessarily take the credit.
Similarly, Briggs and 2GR were dismissed as not great speedsolving ideas; and from the same line of thought, one may consider this method unfit for speedsolving. Nobody forces you to use it and you can certainly verbalise your opinion. However, numerous individuals find it to have potential, so this is undeniably up for debate, it being a bad idea is not something that “I must recognise”. Again, CP-first is certainly not a new idea and I am aware of it now, but an independently developed “different version of Briggs” might have the potential to promise you vastly different results, and that this is not capable of producing something new is not something that “I must recognise”.
That said; this barrage of comments focussing on who gets credit is neither put in a healthy tone, nor is the need of the moment. If you believe you should be calling this method “Briggs variation 1.2” or “Semi-2GR”, do so. And if you’ve looked at all these methods and still decide to stick with “YruRU”, be my guest.

I’m here to push this method out there, and I will continue to do so; call it what you may.
 
Last edited:

Imam Alam

Member
Joined
Apr 2, 2019
Messages
12
@Devagio don't be discouraged by all the negativity around you, remember that each and every creative venture throughout the history of mankind have gone through what you and your ideas are going through now.

go ahead with what you are doing and know that there are also those of us who support new methods development, while knowing fully well that (harsh) criticism is expected.

and I must say, I find your responses to criticism to be very matured, and you express your views quite eloquently (...but in your videos you sounded quite young... how old are you by the way?)

either way, congrats on coming up with your new discovery, and it does not matter whether or not it has similarities with ideas from other people, and it is really exciting to see you updating and developing it consistently.

happy cubing, and thanks for contributing to the community!
 
Last edited:
Top