• 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!

Et tu Brutus? - SSRC Method Proposal

S

Silky

Member
Joined
Apr 5, 2020
Messages
917
Hey guys, Silky here!!

I'm excited to share, with you all, my completed SSRC method proposal. It has taken me 4 years to complete but I am very pleased with the final result. It's been a dredge but here it goes:

Intro: SSRC (Silky Sexy's Roux + Columns) was proposed in 2020. The original concept was a combination of SSC, Roux, and SOAP although was later changed to help simplify and streamline the method. The method was designed to be an intuitive method which boasted a low movecount and low number of algs (since I suck at learning them). Although this is no longer true, the method requiring between 125-177 algs, many of the algs are semi-intuitive. The semi-intuitive semi-algorithmic style of solving is one of its defining characteristics and allows you to influence later steps. Also, this method is really fun :)

Steps:
(1) First Block (7 STM) | <UDFBLR>
(2) Pairs (11.5 STM) | <RrUMSF>
(3) C#LL (9.75 STM) | <RrUFD>
(4) L7E (16.7 STM) | <RrUMS>

Movecount: 44.95 STM

I tested the movecount with an Ao100 - averaging 45.08 STM. More efficient pair building would lower the movecount between 1-2 STM. I believe, with enough practice, Pairs could average ~10.5 STM. Likewise I believe that L7E could average closer to 16.5 STM especially if option selecting is used.

How to:
Steps (1)-(3) are self explanitory. FB and Pairs are all solved intuitively using blockbuilding. C#LL is solved using 42 Algs. L7E is a bit more complicated but there are 2 main approaches.

The first approach is to use 135 algs to solve edge orientation while simultaneously soving the DR edge (EODR). This is follwed by L6EP which is the same as in Roux (4b+4c).

The second approach is to to orient the last 7 edges using 23 algs (L7EO), permute UR UL and DR edges using 60 algs (LRP), and permute the M slice edges (PMS). PMS is completely intuitive - same as in Roux. LRP, as well as iterative EO, were proposed by @Athefre - big thanks to him for all of the help and support over the years <3

Example Solve:

Method: EODR
Scramble: L D L' U2 L' B2 R' B2 L' B2 R2 F2 U F' U' F' L' F' L2

x' F r' B' U2 R2 r' F // FB (7)
r U' M2 U r2 U' r' U' r U' R' // Pairs (11/18)
U' R U R' U' R' F R F' // C#LL (9/27)
U2 R U r U' M' U r' U' r' // EODR (10/37)
U' M2 U' M2 U M2 // L6EP (6/43)

Method: LRP
Scramble: L D L' U2 L' B2 R' B2 L' B2 R2 F2 U F' U' F' L' F' L2

x' F r' B' U2 R2 r' F // FB (7)
r U' M2 U r2 U' r' U' r U' R' // Pairs (11/18)
U' R U R' U' R' F R F' // C#LL (9/27)
U' M' U2 M' U2 M U M2 U2 M' // L7EO (10/37)
U' S' U2 S // LRP (4/41)
U2 M2 // PMS (2/43)

Imrpovements:
There are a few improvements in the works that I want outline. Some of these are under development currently although do not currently have a timeline for release. The first is a replacement to EODR which I call Roux-bee-doux-bee-twoux (RBD2). The idea is that we will solve the DR edge while transforming our EO case into a arrow case. This allows for the use of EOLR (60 algs). This could reduce movecount between 1-1.5 STM. The seond is an variation on step (2). Instead of solving the FR and BR pairs directly we will solve the BR pair in R and the FR pair in U. There would be 77 FR pair algs that could be used and would save between 2-3 STM. This would be usefull since you solve BR pair and then FR pair instead of being pair nuetral. This would be followed up by SBC which solves the the FR Pair and the remain 4 corners (324 algs). SBC's average movecount is nearly the same as C#LL, meaning there would be no penalty to movecount. I've generated these algs although haven't yet organized into a document. The main concern with SBC is possible issues with recognition and ergonomics - I will update as I test more of the algs. If you would like to help further develop this method please feel free to join the SSRC Method Discord here.

Algs:
I've attached a downloadable PDF that includes all of the algs for the first variant (EODR). The excel sheet can be found here. LRP algs can be found here.

Table of Contents:
FR Pair: Page 1
C#LL: Pages 2-5
EODR: Pages 6-7
Extra: Page 8

Notes:
I've include a few Last Slot algs for when the FR edge is stuck in DR (Page 1).
I've also included an approach for intermediate EODR (Page 8). The algs transform your EODR case into 2 of the 3 arrow cases. This helps provide a pathway when learning EODR.

Thanks and Acknowledgements:

Special thanks to @Athefre for their development of LRP and being a great friend and mentor, @trangium for his creation of MCC and Batch Solver which was used heavily (literally could not make this method without batch), @shadowslice e for the inspiration to create this method - specifically SSC, Gilles Roux, again, for his inspiration, and Herbert Kociemba for the creation of CubeExplorer which was also heavily used.

Let me know what you guys think!

Sincerely,
Silky
 

Attachments

I appreciate the direction the method is going. However, the difference versus Roux lies only in the single DR edge that is left unsolved during the second block, and then solved later in a more complex L7E.
If on the other hand you leave out both the DL edge and the DR edge, then solve CLL, you end up in columns, and now, lookhead at the start of the solve is different as it is likely that a good solver can solve 3 pairs in inspection. This is similar to the best LMCF variant which is LMCF-H which also aims to reach columns as quickly as possible (although in a different way). L8E actually may have advantages over L7E because you can solve triplets in the UL/UR/DL/DR domain. Triplets in that domain are extremely efficient in terms of movecount with good ergonomics in the UMD domain.
Nevertheless, nice work, I especially like the L7E progress that has been made.
 
efattah said:
I appreciate the direction the method is going. However, the difference versus Roux lies only in the single DR edge that is left unsolved during the second block, and then solved later in a more complex L7E.
If on the other hand you leave out both the DL edge and the DR edge, then solve CLL, you end up in columns, and now, lookhead at the start of the solve is different as it is likely that a good solver can solve 3 pairs in inspection. This is similar to the best LMCF variant which is LMCF-H which also aims to reach columns as quickly as possible (although in a different way). L8E actually may have advantages over L7E because you can solve triplets in the UL/UR/DL/DR domain. Triplets in that domain are extremely efficient in terms of movecount with good ergonomics in the UMD domain.
Nevertheless, nice work, I especially like the L7E progress that has been made.
Click to expand...

Two reason that I've tended away from L8E is that (1) <RrMUS> is better than <RUMDr> (<RUS> has been proven to be very good in EPLL, not at 100% 1 to 1 but it is promising) and (2) L8E is rather inefficient. When I practiced SSC I averaged around 18-19 AMT. Compare this to SSRC where it averages much closer to L6E. If RBD2 works out 15.5-15.75 STM would be achievable. With efficient blockbuiling it could put the average movecount closer to 43 STM. Compared to Roux with 46.5 (with EOLR) it's a substancial improvement with only the cost of some S moves.

There are definitly improvements to be made in L8E. EO +DR + DL into L6EP could be good but that be 876 cases which is insane - although comparible to LMCF, so not 'impossible'. I'm also assuming that would include a lot of S2 moves which I don't believe are very good. It would be a balance of movecount and ergo for sure - tending toward the movecount side.

I'm interested in your work on LMCF-H. You have anything I would love to take a look - DM me if you're interested.
 
One comment I would add is that ordinary (old) LMCF averages around 42 moves with all the algorithms although ergonomics is poor, and thus TPS is not a match for more modern methods. When Zayn got the new 2x2 WR averaging under 10 moves, I was shocked, because LMCF at 42 moves assumes 12.9 for the corners. If you can average 10.3 for the corners then 'old' LMCF would average under 40 moves, which has been an unattainable goal for any speedsolving method-- it is irrelevant, because even at 39.5 moves average, it is still too slow due to bad ergonomics. LMCF-H actually increases the movecount slightly, but improves ergonomics. If there is an L7E method that averages 15.75 moves and you use this to end 'old' LMCF, then you would average 37.5 moves.
 
@efattah just ran batch for EO+DR+DL and it looks to average between 7-7.5 STM. This would reduce the movecount between 16-17, which is actually pretty good. My original inspiration for SSRC was an offshoot of L8E where you solve DL during CPBL. Assuming you can get to L8E in 24-25 ATM we'd be talking about an average movecount of ~41. I can check some numbers on that, at least for SSC. 3 D layer edges into L5E could also be promising. With L5E you could also sneak some transformation/psuedo stuff. One example would be solving DF DB and UF and doing D M2 or D' M2 to set up L5E. Anthoer would be solving DL UF UR and setting up with r2. 428 algs for D edges and 245 for L5E.

ProStar said:
No please anything but Latin flashbacks
Click to expand...

Nah, I love Latin <3 Happy Ides of March o7

Running for cube said:
Oh wait, I’m so stupid 😂. Apparently I forgot how roux worked and I imagined it being used with 8 corners and inserts. This is why I usually don’t post in intellectual threads, to not embarrass myself.
Click to expand...

Lol, all good.
 
abunickabhi said:
Option selecting is an advanced thing right?
Click to expand...

Yes. You'd switch between LRP for arrow cases and RBD2 into EOLR for the rest. The nice thing is your recognition doesn't change by much since you recognize EO for both vs Mehta where you had different recognition for each option.
 
@Silky you are saying you ran a simulation to solve DR/DL while simultaneously orienting the remaining 6 edges and it averages 7.0 to 7.5 moves? With around 800 algorithms?
That seems really low considering L5E, solving UL and orienting the remaining 4 edges averages around 8.0 moves....
If true though that would be a huge breakthrough.
 
efattah said:
@Silky you are saying you ran a simulation to solve DR/DL while simultaneously orienting the remaining 6 edges and it averages 7.0 to 7.5 moves? With around 800 algorithms?
That seems really low considering L5E, solving UL and orienting the remaining 4 edges averages around 8.0 moves....
If true though that would be a huge breakthrough.
Click to expand...

Yup, ran it through batch. Around 50ish cases failed so, to be safe, I'd say closer to 7.5 stm. Note that this doesn't include ABFs. It's between 800-900 algs I believe
 
UPDATE: Slowly making progress on RBD2. Hoping to finish up by the first week of April. Spotted some mistakes in the alg sheets - updated the google sheets page accordingly. Will re-upload the PDF once I've finished RBD2.
 
You must log in or register to reply here.
Back
Top