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

Thom S.

Member
Joined
Sep 26, 2017
Messages
1,292
What do you think of the hybrid method that I created to use as a step up from basic method.

One of the most common proposals and while it's maybe better than CFOP in terms of movecount it's inferior than Roux.
Think about it ULUR is about the same as DFDB but all 4c cases are better than all the Edge-only Perms
 
Joined
Jul 12, 2016
Messages
308
YouTube
Visit Channel
ZZ-HIV lol

ZZ-HIV Type A

1. EO+1 edge solved
2. Pretty much Heise at this point

ZZ-HIV Type B

1. EO+2 cross edge adjacent to each other solved
2. 2x2 Block -> 2x2x3 Block
3. Another 2x2x1 Block on LL while insert F2L
4. ZZ-Tripod/L3C or ZBLL with 2x2 Block
 

abunickabhi

Member
Joined
Jan 9, 2014
Messages
6,687
Location
Yo
WCA
2013GHOD01
YouTube
Visit Channel
The problem is that it will often take 3 comms to solve lse, just try it for yourself and see. At this point you will probably be using more moves than a standard lse solution.
Yeah I have tried it out ,and I have mixed bags results,
sometimes it is just 2 easy comms, and in other cases it is just better to do the LSE.

I think a middle method can be developed from both of them, for eg,
if there is an flipped edges in their spot , then doing LSE or good flipping alg will be good.
Otherwise if there is a solved piece, then an easy 2 comms of 3-style or even one 5-cycle alg.
 

Hazel

Premium Member
Joined
Apr 1, 2017
Messages
1,681
Location
in your walls :3
This gave me a bit of an idea of another way to possibly do LSE:
Put the 2 D-layer edges into the D-layer while solving centers, not worrying about permutation, as long as they're both either oriented or not oriented. Then, do 1 alg to solve everything. This would have about 29*4= 116 cases, plus or minus, recognition wouldn't be any harder than ELL.
 

_zoux

Member
Joined
Mar 11, 2018
Messages
101
Another generic ZZ variant idea

ZZ-C#

eoline -> f2l-1 -> OLLS (OLS but you don't care for D corner orientation) -> TPLL

Pros

-Way fewer algs than C itself
-No problems with fixed slot, since there's so few OLLS cases, so you can learn mirrors, and then just ADF for TPLL
-OLLS is 2 gen
-OLLS algs are just good OLS algs
-Actually pretty effictent (mid 40s)
Cons

Recognition is eh (edit: it's ok)
A lot of algs (~200 total)
TPLL algs might be pretty bad, but i'm not sure


There were a idea of CPOLLS/TEPLL, but it seems like too many algs

here's dum solve
L' D B' U F L2 U F2 D2 R2 F2 D R' D2 B2 L U' B R F' // Scramble

x M' U D' F R D F2 // 7,7 // eoline

U R' U2 R U' R U R // 8,15 // first square

L' U2 L2 U2 L' U' L' // 7,22 // second square

U R U' L' U' M' x' // 6,28 // pair

R U2 R' U R U2 R' // 7,35 // OLLS

B U' F2 U B' R2 U R2 U R2 U2 R2 U F2 // 14,49 // TPLL

ok thanks bye
 
Last edited:

Sion

Member
Joined
Dec 13, 2015
Messages
1,067
Location
New York
I did this decent solve that I don't know exactly what method I did, but it seemed decently efficient.

https://alg.cubing.net/?alg=x2_y_R2..._L_B_R_D_B-_F2_D-_L_D-_F- &title=This thing

Scramble:
R2 D2 R2 D2 B2 D2 B' R2 B' F2 D2 L B R D B' F2 D' L D' F'

x2 y R2 F U R u' R2 u' //FB (7)
U' M' r U' r U2 R2 M // 2x2x2 DBR (8)
U' M' U' M U R M' U2 M// EO+DF (9)
U R' U R U' R' U R U R'// 1x2x2 U (10)
R U R' U' z' //Reduction to L3C (4)
L' U2 L' D' L U2 L' D L2// L3C (10)
 

presley

Member
Joined
Jul 24, 2018
Messages
15
Location
Taiwan
I create a new method.

The first step of this method is to do a 2x2x3 block as well as the Petrus method, but all the rest steps is not the same as the Petrus method and this method is a group reducing method, reduced to the R, U face rotations group and the group that does not destroy completed pairs, no F2L, no PLL, OLL, and some steps have their own ideas.

So I give it a new name, Reduce R, U face rotations group and retain Pairs, referred to as the RUP method.

Step 1, complete a 2x2x3 block
Step 2, Reducing to R, U face rotations group.
Step 3, complete 2 pairs
Step 4, complete the third pair
Step 5, complete the 4th pair
Step 6, expand into 3 pairs and 1 1x2x2 block

This method is a still developing method.

The detail I put it on the web site
https://presleygit.github.io/index_eng.html
 

shadowslice e

Member
Joined
Jun 16, 2015
Messages
2,923
Location
192.168. 0.1
YouTube
Visit Channel
I think you might be on track to recreating somehing akin to NCPB 2.0 (albeit with a petrus as opposed to a roux block). I'd be interested to see where you end up though as I don't think anyone has yet come up with a really competitive method where CP on its own is done before L4C. You might like to have a look at 2GR, Briggs/B2, ZZ-porky and both NCPB and NCPB 2.0
 
Last edited:

presley

Member
Joined
Jul 24, 2018
Messages
15
Location
Taiwan
Because this method is a pure reducing group method.
So I change the steps name of this method like below.

RUP method
Step 1, complete a 2x2x3 block
Step 2, Reducing to R, U face rotations group.
Step 3, Reducing to the group of retaining 2 pairs
Step 4, Reducing to the group of retaining 3 pairs
Step 5, Reducing to the group of retaining 4 pairs
Step 6, Reducing to the group of retaining 3 pairs and 1 1x2x2 block

https://presleygit.github.io/index_eng.html
 

meskelto

Member
Joined
Aug 23, 2018
Messages
18
Location
Surrey, England
WCA
2013SKEL01
Hey. I have searched around for this concept that I have thought of but I haven’t come across anything online or in the threads. The algorithms are not ready yet, so I decided to put my idea out there and to get your thoughts on it.

It is a LSLL method that is inspired by Fish and Chips (F&C) that is used for EO methods, most likely ZZ and Petrus. It should hopefully reduce the gap further between ZBLL (about 23 moves) and the SIMPLE version of F&C developed by @mDiPalma (about 25 moves) without resorting to using so many algs. Since the first step is to solve one edge piece, I have decided to call this LSLL method One Piece (which sounds familiar...). Anyway, the steps are outlined below:

1: Solve to F2L-1 with EO.
2: Solve the final F2L edge, ignoring the corner.
3: Solve all the edges of the LL and any two corners within the LL and belonging to LL using Siamese Fish (SF) algs (a subset of the ZBLLs).
4: L3C.

The idea is to try to save moves by only inserting the final F2L edge and ignoring the corner. Usually the LS is solved in 7 moves (from the SIMPLE thread), and just the edge on its own is 2.6 moves, which reduces to 2 if we always try to cancel from solving the square. Therefore, this saves 5 moves overall.

The L3C should be solved in roughly the same number of moves as in F&C, possibly a little higher (about 9.5 moves). There should be potential AUFs before the SF algorithm and at the end of the solve, so: 0.75 + 0.75 = 1.5 moves. Between SF alg and L3C, any AUF is absorbed into the L3C move count.

Overall move count = 2 + [SF alg] + 9.5 + 1.5 = 13 + [SF alg]

So in order for this method to be worth doing (at least in terms of the move count) the SF algorithms need to be less than 12 moves on average, which seems entirely possible.

Also, since there is a corner trapped in the F2L, look ahead into the L3C step is relatively simple as you only need to track one corner (in fact, only the orientation) to predict the final step. This allows for a more pause-less solve than most 2-step systems, and people could even train themselves to see almost the entire LSLL in one-look in speedsolves.

Since I haven’t developed the SF algorithms yet, I am not 100% sure how many algorithms will be needed and what their average move count will be, but I will try to estimate them here. Any help with this estimate would be appreciated!

Note: If the F2L corner is accidentally solved then just do normal F&C.

Edit:
Also, I could just find algs that affect all five corners. This would reduce the alg count since more cases are covered per alg, and maybe the move count would be lower as well. However, the case recognition would be more difficult (more corners to look at), it is harder to look ahead to L3C and you may have to rotate or use mirrors to get the F2L corner slot in the correct position (less of a problem with L3C). As @Spencer131 said this would be just like Heise, but purely using algs. I guess doing this could be useful for FMC so maybe I'll produce an alg set for this one day, but the version I described above is better for speedsolving.

Alg Count:
We begin with calculating the number of LL+C cases. There are only 3 edge cases: adjacent swap, opposite swap and solved. There are 5! permutations and 3^5 orientations, divided by 2 since only even swaps are allowed overall and divided by 3 since for every clockwise twist there is an anti-clockwise one.

The number of corner cases per edge case = 5! X 3^5 / (2 X 3) = 4860

Note that by rotating corner cases (not the corners themselves) about edge cases in LL, we find identical cases. For example, rotating an A perm corner case about the solved edge case. This means we divide the number of corner cases by 4 for the solved edge case and 2 for the opposite swap case. (Remember, you can AUF when considering F2L corner).

I think that if the corner cases themselves have rotational symmetry then this doesn’t add as much to the cases we can eliminate. So the final number of cases is a bit of an under-estimate, but due to the fifth corner there shouldn’t be too many of these cases.

Therefore, the total number of unique LL+C cases = 4860 + 4860/2 + 4860/4 = 8505

Since we deal with the solved F2L corner case with F&C, we do not need to consider 1/15 of the LL+C cases. So the number of LL+C cases we need to consider is 7938.

Now to calculate roughly how many cases each SF alg covers. Suppose we solve all the edges and any two corners in LL. Then we are left with 3 corners to solve, and the total number of cases for these corners is:

L3C cases = 3! X 3^3 / (2 X 3) = 27;

but take away 3 to get 24 (from solved F2L corner cases since these never come up so cannot be covered).

Since each SF alg accounts for 6 corner pair cases (well, most of them; I'm looking at you H perm) for a given edge case:

LL+C cases covered per SF alg = 6 X 24 = 144

This is an over-estimate actually, since multiple corner pair cases can appear from the same alg in one LL+C case; I think this happens for 16 LL+C cases. So the actual number is 128.

Lastly, we ignore SF skips; a SF alg which does nothing covers two corner cases, so: 2 X 24 - 2 (not 16 due to symmetry) = 46 cases of SF skip.

Hence, the minimum number of SF algs required for full coverage is: (7938 - 46) / 128 = 61.7

So 62 SF algs is the estimated minimum amount for full coverage.

So I estimate that the minimum number of SF algorithms needed is about 62. It is likely that more algs would be used for the SF set which optimises move count, possibly bringing the total up to about 80-100. I think for most people, learning this number of algs is very doable.

Have the corner in F2L always on DFR/DFL, helped by using d/d’ moves when you AUF. There are 2 cases when looking at LL; either the two corners are adjacent or diagonally opposite. AUF to have both corners in front or one corner above the corner in F2L. Then there are 52 cases, but this can be reduced by 1/2 if we use inverses to get 26 L3C algs.

This could be reduced to 13 if we use L/R moves to set up a diagonal case from an adjacent one (or vice versa), but this obviously increases move count.

So the minimum number of L3C algorithms is 26. Of course knowledge of commutators would reduce the L3C alg set to zero, but I think this way can be useful in finding more ergonomic solutions.

Move Count:

The average move count for full ergonomic ZBLL is about 14.5 moves (again taken from SIMPLE thread), so I would say 10-12 moves is a realistic target considering we are selecting less than 100/500 algs.

More about L3C prediction:
One system for predicting L3C is given. I hope this is easier to do in practice than it is to explain!

1: Find SF alg and know (after correct AUF) the two positions of the two unsolved corners in LL. Pick a corner belonging to LL to track.

2: Note corner trapped in F2L; if it is correctly permuted (at home) then so will the corner we are tracking after the SF alg, and vice versa. If the trapped corner is not at home then it tells you where the other corner goes, since the corner we are tracking must go to where the trapped corner wants to go. The final corner must go to the last available position, and so the permutation is deduced purely from looking at the trapped corner.

3: So we only need to know the orientation of the corner we are tracking, since the trapped corners’ orientation is fixed and the orientation of the other corner is deduced from the other two. This makes it easy to look ahead and if one knew the orientation effect of the SF alg then both SF alg and L3C can be found in one look.

Alternatively, you might know the alg you are using well enough that you can just predict the state of the corner you track easily. But the system above might be useful if you recognise the SF alg as half a ZBLL.

So hopefully I’ll finish the alg set soon, and I think I’ll start a new thread about One Piece LSLL if anything comes of it. Let me know about any questions or remarks that you have.
 
Last edited:

Sue Doenim

Member
Joined
Nov 9, 2016
Messages
448
Hey. I have searched around for this concept that I have thought of but I haven’t come across anything online or in the threads. The algorithms are not ready yet, so I decided to put my idea out there and to get your thoughts on it.

It is a LSLL method that is inspired by Fish and Chips (F&C) that is used for EO methods, most likely ZZ and Petrus. It should hopefully reduce the gap further between ZBLL (about 23 moves) and the SIMPLE version of F&C developed by @mDiPalma (about 25 moves) without resorting to using so many algs. Since the first step is to solve one edge piece, I have decided to call this LSLL method One Piece (which sounds familiar...). Anyway, the steps are outlined below:

1: Solve to F2L-1 with EO.
2: Solve the final F2L edge, ignoring the corner.
3: Solve all the edges of the LL and any two corners using Siamese Fish (SF) algs.
4: L3C.

The idea is to try to save moves by only inserting the final F2L edge and ignoring the corner. Usually the LS is solved in 7 moves (from the SIMPLE thread), and just the edge on its own is 2.6 moves, which reduces to 2 if we always try to cancel from solving the square. Therefore, this saves 5 moves overall.

The L3C should be solved in roughly the same number of moves as in F&C, possibly a little higher (about 9.5 moves). There should be potential AUFs before the SF algorithm and at the end of the solve, so: 0.75 + 0.75 = 1.5 moves. Between SF alg and L3C, any AUF is absorbed into the L3C move count.

Overall move count = 2 + [SF alg] + 9.5 + 1.5 = 13 + [SF alg]

So in order for this method to be worth doing (at least in terms of the move count) the SF algorithms need to be less than 12 moves on average, which seems entirely possible.

Also, since there is a corner trapped in the F2L, look ahead into the L3C step is relatively simple as you only need to track one corner (in fact, only the orientation) to predict the final step. This allows for a more pause-less solve than most 2-step systems, and people could even train themselves to see almost the entire LSLL in one-look in speedsolves.

Since I haven’t developed the SF algorithms yet, I am not 100% sure how many algorithms will be needed and what their average move count will be, but I will try to estimate them here. Any help with this estimate would be appreciated!

Note: If the F2L corner is accidentally solved then just do normal F&C.

Alg Count:
We begin with calculating the number of LL+C cases. There are only 3 edge cases: adjacent swap, opposite swap and solved. There are 5! permutations and 3^5 orientations, divided by 2 since only even swaps are allowed overall and divided by 3 since for every clockwise twist there is an anti-clockwise one.

The number of corner cases per edge case = 5! X 3^5 / (2 X 3) = 4860

Note that by rotating corner cases (not the corners themselves) about edge cases in LL, we find identical cases. For example, rotating an A perm corner case about the solved edge case. This means we divide the number of corner cases by 4 for the solved edge case and 2 for the opposite swap case. (Remember, you can AUF when considering F2L corner).

I think that if the corner cases themselves have rotational symmetry then this doesn’t add as much to the cases we can eliminate. So the final number of cases is a bit of an under-estimate, but due to the fifth corner there shouldn’t be too many of these cases.

Therefore, the total number of unique LL+C cases = 4860 + 4860/2 + 4860/4 = 8505

Since we deal with the solved F2L corner case with F&C, we do not need to consider 1/15 of the LL+C cases. So the number of LL+C cases we need to consider is 7938.

Now to calculate roughly how many cases each SF alg covers. Suppose we solve all the edges and any two corners in LL. Then we are left with 3 corners to solve, and the total number of cases for these corners is:

L3C cases = 3! X 3^3 / (2 X 3) = 27;

but take away 3 to get 24 (from solved F2L corner cases since these never come up so cannot be covered).

Since each SF alg accounts for 6 corner pair cases (well, most of them; I'm looking at you H perm) for a given edge case:

LL+C cases covered per SF alg = 6 X 24 = 144

This is an over-estimate actually, since multiple corner pair cases can appear from the same alg in one LL+C case; I think this happens for 16 LL+C cases. So the actual number is 128.

Lastly, we ignore SF skips; a SF alg which does nothing covers two corner cases, so: 2 X 24 - 2 (not 16 due to symmetry) = 46 cases of SF skip.

Hence, the minimum number of SF algs required for full coverage is: (7938 - 46) / 128 = 61.7

So 62 SF algs is the estimated minimum amount for full coverage.

So I estimate that the minimum number of SF algorithms needed is about 62. It is likely that more algs would be used for the SF set which optimises move count, possibly bringing the total up to about 80-100. I think for most people, learning this number of algs is very doable.

Have the corner in F2L always on DFR/DFL, helped by using d/d’ moves when you AUF. There are 2 cases when looking at LL; either the two corners are adjacent or diagonally opposite. AUF to have both corners in front or one corner above the corner in F2L. Then there are 52 cases, but this can be reduced by 1/2 if we use inverses to get 26 L3C algs.

This could be reduced to 13 if we use L/R moves to set up a diagonal case from an adjacent one (or vice versa), but this obviously increases move count.

So the minimum number of L3C algorithms is 26. Of course knowledge of commutators would reduce the L3C alg set to zero, but I think this way can be useful in finding more ergonomic solutions.

Move Count:

The average move count for full ergonomic ZBLL is about 14.5 moves (again taken from SIMPLE thread), so I would say 10-12 moves is a realistic target considering we are selecting less than 100/500 algs.

More about L3C prediction:
One system for predicting L3C is given. I hope this is easier to do in practice than it is to explain!

1: Find SF alg and know (after correct AUF) the two positions of the two unsolved corners in LL. Pick a corner belonging to LL to track.

2: Note corner trapped in F2L; if it is correctly permuted (at home) then so will the corner we are tracking after the SF alg, and vice versa. If the trapped corner is not at home then it tells you where the other corner goes, since the corner we are tracking must go to where the trapped corner wants to go. The final corner must go to the last available position, and so the permutation is deduced purely from looking at the trapped corner.

3: So we only need to know the orientation of the corner we are tracking, since the trapped corners’ orientation is fixed and the orientation of the other corner is deduced from the other two. This makes it easy to look ahead and if one knew the orientation effect of the SF alg then both SF alg and L3C can be found in one look.

Alternatively, you might know the alg you are using well enough that you can just predict the state of the corner you track easily. But the system above might be useful if you recognise the SF alg as half a ZBLL.

So hopefully I’ll finish the alg set soon, and I think I’ll start a new thread about One Piece LSLL if anything comes of it. Let me know about any questions or remarks that you have.
This isn't exactly the same method as what you were describing, but it looks pretty similar. I'd suggest you take a look.
CR2
 
Top