I'm not even sub15 with CFOP (my main method), how am I supposed to be sub15 with SSC quickly enough?
I'm not going to abandon CFOP because I invested so much time and effort in it already. If I learn SSC, it would be a secondary method but if one day I average sub10 with it I'd be totally willing to "sacrifice" one comp not using CFOP, just proving SSC can be fast.
Eh, "new" method. Almost definitely thought of before no name for it. If someone finds it interesting they can think of a name but I don't think it is good for speed though it can be efficient in some scenarios.
This is based on human thistlethwaite but doesn't break the steps down so much.
Basically, treat opposite colours as the same until the final step (ie green=blue, red=orange, white=yellow) and blockbuild. Below is just a suggestion based on tripod but ideally you should be able to do anything from petrus to roux to pcms to triangular fransisco.
1) 2x2x3 block- if you are good at blockbuilding you can often plan this in inspection. I can do it about half the time. (7/7)
2) finish F2L-1 (5/12)
3) 2x2 block on U (5/17)
4) finish 3 colour reduction (all faces are opposite colours)-some algs but no idea how many accurately-maybe 50 (8?/25)
5) final permutation of pieces (12/37)- from heise's site
Remember this is just estimate and I'm probably nowhere near exact.
1) low movecount
2) easy blockbuilding
3) many blocks will just appear
1) double turns aren't nice to fingertrick
2) needs a lot of flexibility though fmcers may like it
3) lots don't in first step
4) each piece essentially has to be solved twice
5) could be a lot of algs if you do a lot of variants
So general feelings: could be fun, not particularly good for speedsolving, some applications in FMC and looks cool
Eh, "new" method. Almost definitely thought of before no name for it. If someone finds it interesting they can think of a name but I don't think it is good for speed though it can be efficient in some scenarios.
This is based on human thistlethwaite but doesn't break the steps down so much.
Basically, treat opposite colours as the same until the final step (ie green=blue, red=orange, white=yellow) and blockbuild. Below is just a suggestion based on tripod but ideally you should be able to do anything from petrus to roux to pcms to triangular fransisco.
1) 2x2x3 block- if you are good at blockbuilding you can often plan this in inspection. I can do it about half the time. (7/7)
2) finish F2L-1 (5/12)
3) 2x2 block on U (5/17)
4) finish 3 colour reduction (all faces are opposite colours)-some algs but no idea how many accurately-maybe 50 (8?/25)
5) final permutation of pieces (12/37)- from heise's site
Remember this is just estimate and I'm probably nowhere near exact.
1) low movecount
2) easy blockbuilding
3) many blocks will just appear
1) double turns aren't nice to fingertrick
2) needs a lot of flexibility though fmcers may like it
3) lots don't in first step
4) each piece essentially has to be solved twice
5) could be a lot of algs if you do a lot of variants
So general feelings: could be fun, not particularly good for speedsolving, some applications in FMC and looks cool
This sounds great but the move count doesn't seem to make sense. In theory, shouldn't solving the pieces "twice" technically require more moves than simply efficiently solving in the first place? Although I can see how this would be good if you want to be efficient in a speedsolve since it's easier to blockbuild without as much thinking. And recognition for the last step probably sucks a lot.
This sounds great but the move count doesn't seem to make sense. In theory, shouldn't solving the pieces "twice" technically require more moves than simply efficiently solving in the first place? Although I can see how this would be good if you want to be efficient in a speedsolve since it's easier to blockbuild without as much thinking. And recognition for the last step probably sucks a lot.
No, in the same way human thustlethwaite doesn't: the block options are much more expansive and require fewer moves to do: for example, you on the typical scramble, you can usually find a 2x2 block in about 3 moves, a 2x2x3 in 7 etc.
Also, the final permutation is intuitive not alg based so no recog needed.
No, in the same way human thustlethwaite doesn't: the block options are much more expansive and require fewer moves to do: for example, you on the typical scramble, you can usually find a 2x2 block in about 3 moves, a 2x2x3 in 7 etc.
Also, the final permutation is intuitive not alg based so no recog needed.
Okay but even so the last step of this method doesn't seem very good. Is the last step just solving from EOBelt+CO? If so isn't this just a less efficient SSC?
Okay but even so the last step of this method doesn't seem very good. Is the last step just solving from EOBelt+CO? If so isn't this just a less efficient SSC?
Eh, "new" method. Almost definitely thought of before no name for it. If someone finds it interesting they can think of a name but I don't think it is good for speed though it can be efficient in some scenarios.
This is based on human thistlethwaite but doesn't break the steps down so much.
Basically, treat opposite colours as the same until the final step (ie green=blue, red=orange, white=yellow) and blockbuild. Below is just a suggestion based on tripod but ideally you should be able to do anything from petrus to roux to pcms to triangular fransisco.
1) 2x2x3 block- if you are good at blockbuilding you can often plan this in inspection. I can do it about half the time. (7/7)
2) finish F2L-1 (5/12)
3) 2x2 block on U (5/17)
4) finish 3 colour reduction (all faces are opposite colours)-some algs but no idea how many accurately-maybe 50 (8?/25)
5) final permutation of pieces (12/37)- from heise's site
Remember this is just estimate and I'm probably nowhere near exact.
1) low movecount
2) easy blockbuilding
3) many blocks will just appear
1) double turns aren't nice to fingertrick
2) needs a lot of flexibility though fmcers may like it
3) lots don't in first step
4) each piece essentially has to be solved twice
5) could be a lot of algs if you do a lot of variants
So general feelings: could be fun, not particularly good for speedsolving, some applications in FMC and looks cool
I tried it. Seems nice, Just need to figure out the final step algorithms. seems like unless you have a crappy color scheme where in less light opposite colors look alike it could be really hard to recognize. but I am interested!!!
also, I can't find the separation algorithms on Ryan Heise's site. Do you know where I can find them?
I tried it. Seems nice, Just need to figure out the final step algorithms. seems like unless you have a crappy color scheme where in less light opposite colors look alike it could be really hard to recognize. but I am interested!!!
also, I can't find the separation algorithms on Ryan Heise's site. Do you know where I can find them?
There are no algs for the final step: its completely intuitive apart from maybe N perms. It is identical to the very last step in Thistlethwaite.
Example solve based on Roux
Scramble: R2 F' L2 B D2 U2 B D2 B' F2 D2 U' R2 U' B2 L' D F2 R U
y' U2 F (lol)//FB (2/2)
U R' U2 r2 U r' U R//SB (10/12)
L U' R' U L' U' R//CMLL (7/19)
U' M' U M' U M' U2 M U' (9/28)
If you want to finish from here you can I'm just tired as f*** so cba
It actually has six times the number of states of the last step in Thistlethwaite, as the square group <U2,D2,L2,R2,F2,B2> has two non-obvious corner restrictions.
The corners can be divided into two tetrads that never mix if you apply only half turns, and a half turn effects an odd permutation on each of these tetrads. If the permutation signs don't match between the tetrads, then you have an "N perm" kind of case. This gives a factor-of-2 increase compared to the square group.
For either tetrad, all 24 permutations are possible since every 2-cycle within a tetrad is possible, which generates S_4. If we consider the stabiliser of one of the tetrads in the square group (i.e. if we solve one tetrad first), this subgroup has exactly four elements and is abelian; the only such subgroup of A_4 is V_4. Since |A_4|/|V_4| = 12/4 = 3, this gives another factor-of-3 increase compared to the square group. Representatives of the two non-identity cosets are the UFL-UBR-DFR corner cycle and its inverse.
So if you hit a corner 3-cycle case, you could either use two N perms (sounds bad) or learn just one additional alg to deal with it. Not quite "no algs", but needing only two algs is still pretty neat. The downside is that these algs aren't short, so you inflate your move count by 12-13 moves five-sixths of the time. HTA avoids this issue by solving the corners completely (not just in the "opposite colours" sense).
It actually has six times the number of states of the last step in Thistlethwaite, as the square group <U2,D2,L2,R2,F2,B2> has two non-obvious corner restrictions.
The corners can be divided into two tetrads that never mix if you apply only half turns, and a half turn effects an odd permutation on each of these tetrads. If the permutation signs don't match between the tetrads, then you have an "N perm" kind of case. This gives a factor-of-2 increase compared to the square group.
For either tetrad, all 24 permutations are possible since every 2-cycle within a tetrad is possible, which generates S_4. If we consider the stabiliser of one of the tetrads in the square group (i.e. if we solve one tetrad first), this subgroup has exactly four elements and is abelian; the only such subgroup of A_4 is V_4. Since |A_4|/|V_4| = 12/4 = 3, this gives another factor-of-3 increase compared to the square group. Representatives of the two non-identity cosets are the UFL-UBR-DFR corner cycle and its inverse.
So if you hit a corner 3-cycle case, you could either use two N perms (sounds bad) or learn just one additional alg to deal with it. Not quite "no algs", but needing only two algs is still pretty neat. The downside is that these algs aren't short, so you inflate your move count by 12-13 moves five-sixths of the time. HTA avoids this issue by solving the corners completely (not just in the "opposite colours" sense).
Oh ok I see I sort if missed that part when skimming over the email. It's easily rectifiable though: just add maybe 2-3 moves if we have to separate corners in the first step and maybe one more move to do the algs so this may be mostly inconsequential. Though I don't think that method was for speed anyway (and the movecounts are pretty hypothetical anyway).
In simple put terms: treat 2 sets of opposite colours as the same and one set as different.
maxwellj02 (from Reddit, I don't think he's on SS) and I were talking about doing PLL parity at the same time as OLL parity. A couple of the common OLL parity algs just do OLL parity, but some of the others do double parity. His suggestion was to recognise PLL parity before OLL parity, and then choose one of two OLL parity algs so that you would solve PLL parity at the same time. But of course, even if the algs are good, recognition would be terrible. I've also seen this suggested a few times before.
Something I haven't seen before was using the fact that almost all the good OLL parity algs solve the same OLL case. Both for double parity and just OLL parity. Not only this, but most pieces are oriented too, making recognition easier. So here's a LL method when you have OLL parity:
Do an OLL algorithm which will leave you with this OLL case. You'll have to learn which OLL to use when, which is I think another 57 cases to learn. But no new algorithms (or very few).
Recognise PLL parity. Much easier to do with all the pieces oriented.
Do an OLL parity algorithm to solve OLL and PLL parity (if necessary) in one step. Two algs for this step, one of which you already know.
PLL! And you never get double parity.
Advantages:
Fewer moves if you get PLL parity, same number of moves otherwise.
You don't have to recognise PLL parity after OLL, which means you can use faster recognition systems like 2-sided PLL recog.
In fact since you've recognised PLL before doing OLL parity you'll often know which PLL you're getting anyway, so you can have zero pause between OLL and PLL.
Not many new algorithms at all.
Disadvantages:
PLL parity recognition is a little harder. You can see more pieces at once but not all of them are oriented.
More pauses in LL, unless you can predict PLL before OLL parity.
The number of cases you need to learn is quite large (I think it's ~60).
What do you think? Any advantages/disadvantages I've missed?
Pretty sure I've posted about that before and got no interest whatsoever. I had the idea while working on doing CLL/ELL if I had OLL parity, so I could take care of both parities at once. I have some badly organised algs for both forcing the correct CLL case (for the cases where it's better than just doing CLL), and also an incomplete list for 1-looking the rest of the solve. PM me an email address if you want me to send them, they're in an Excel sheet. I've not found the time to learn it yet, so if you give it a go let me know how well it works.
I have also thought about his but not tried it much. My idea was to solve an OLL case that would leave a single edge flipped. Then do two-sided PLL recognition on the opposite good sides. After PLL you will be left with either a single edge flip, or an opposite edge swap with one of those flipped. So two OLL parity algs needed. I never got round to hunting down good algs. I just assumed that opposite swap would likely have better algs than adjacent swap. Two-sided recognition on opposite sides would take a bit of getting used to but with lookahead shouldn't be too bad.
Pretty sure I've posted about that before and got no interest whatsoever. I had the idea while working on doing CLL/ELL if I had OLL parity, so I could take care of both parities at once. I have some badly organised algs for both forcing the correct CLL case (for the cases where it's better than just doing CLL), and also an incomplete list for 1-looking the rest of the solve. PM me an email address if you want me to send them, they're in an Excel sheet. I've not found the time to learn it yet, so if you give it a go let me know how well it works.
I have also thought about his but not tried it much. My idea was to solve an OLL case that would leave a single edge flipped. Then do two-sided PLL recognition on the opposite good sides. After PLL you will be left with either a single edge flip, or an opposite edge swap with one of those flipped. So two OLL parity algs needed. I never got round to hunting down good algs. I just assumed that opposite swap would likely have better algs than adjacent swap. Two-sided recognition on opposite sides would take a bit of getting used to but with lookahead shouldn't be too bad.
Opposite swap is definitely better than adjacent swap. But I don't that it would always give you an opposite swap if you recognised the PLL case from just looking at L/R, unless the edges were phased, which doesn't happen often. Instead I think you'd have to recognise using the two sides which had opposite coloured edges, meaning you'd use adjacent sides 2/3 of the time and opposite sides 1/3 of the time.
But I don't that it would always give you an opposite swap if you recognised the PLL case from just looking at L/R, unless the edges were phased, which doesn't happen often. Instead I think you'd have to recognise using the two sides which had opposite coloured edges, meaning you'd use adjacent sides 2/3 of the time and opposite sides 1/3 of the time.
