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

Teoidus

Member
Joined
Feb 11, 2016
Messages
573
Location
Char
o wait guys zz-porky v2 is neat and all but like

all we need is a way to reduce corner permutation to the set solvable wholly <L,U> and then wholly <R,U> in inspection and we'll have an actual missing link filler

we know that a permutation of 8 corners can be expressed in terms of a key swap + position of BLD sticker. once forcing all the left block pieces into L and U, this key swap + BLD can be converted into a swap of two pieces both on <L,U>. The left block is solved <L,U> so the identity of the pieces that need to be swapped won't change (since permutation fix invariant under <L,U>)
 

Sue Doenim

Member
Joined
Nov 9, 2016
Messages
448
I've been looking for a way to better the roux method, and I have tried doing corner permutation while finishing the second block, with an LS mindset. If this is done, OLLCP can be done with only 57 algorithms (as opposed to 331) and mostly R, r, U, and M moves. This also brings up a question: why is CPLS done like CLS, instead of with the full F2L pair? I've generated the full-pair cases, and they are not bad.
 

Teoidus

Member
Joined
Feb 11, 2016
Messages
573
Location
Char
Hm, might be that it's more moves to make the pair and so on average you get better movecounts out of insert edge + CLS vs make pair + insert pair & CLS
 

Teoidus

Member
Joined
Feb 11, 2016
Messages
573
Location
Char
Free roux also goes by simultaneous or non-linear blocks i think. can get you some really nice movecounts
 

Teoidus

Member
Joined
Feb 11, 2016
Messages
573
Location
Char
Like a pinky pie with psuedo2gen algs only:
CPFB (10)
SBsq (7)
LE + ULUR/UFUB on D (~6?)
LC + CO + EO (12?)
L6E (8)
= 43 STM avg

Thoughts? Better ways to finish L12P (LS + CO + L6E)?
 

Sue Doenim

Member
Joined
Nov 9, 2016
Messages
448
I know Old Pochmann, and I was looking into learning M2/R2. However, I was kind of disappointed with so many x rotations. I then began thinking about possibly using M moves instead of M2, so you can put it in place oriented without requiring rotations. Is this possible? I haven't thought of a way to make it work, but maybe someone else could. If so, It could be a much faster method.
 

Teoidus

Member
Joined
Feb 11, 2016
Messages
573
Location
Char
Unfortunately not, you'll still have cases where when setting up to the buffer, you either need to use F/B moves or an x rotation. What's more is that you'll actually have to alternate between using M and M' to solve pieces

What you could do is consider setting up pieces into UF instead of into UB. This would let you use F moves in your setups (for example things like F R F')
 

xyzzy

Member
Joined
Dec 24, 2015
Messages
2,878
all we need is a way to reduce corner permutation to the set solvable wholly <L,U> and then wholly <R,U> in inspection and we'll have an actual missing link filler

Textbook group theory result says that there are 3600 (out of 8!=40320) corner permutations that can be solved like that, so setting up the corners to one of these ⟨R,U⟩ ⟨L,U⟩ states probably takes 1-3 moves on average. The hard parts are (i) how to recognise if we're in this set of states and (ii) how to get there. And once we're in this set, we no longer have to track anything! If we solve the left block using only L and U moves, we'll automatically be reduced to 2-gen.

Unfortunately this gets messier once we take the edges into account. We have to do EO and get the LD/LF/LB edges out of the R layer, which probably takes around 5 moves, and we have to track CP throughout that. (Or if we leave the M slice free, we don't have to do EO, which might be better?)

The left block is solved <L,U> so the identity of the pieces that need to be swapped won't change (since permutation fix invariant under <L,U>)

I don't think this works. Just because it's invariant under ⟨R,U⟩ doesn't mean it has to be invariant under every 2-gen subgroup.

Let's say the scramble is just F2 M2 F M2 F2 M2 F M2 (for simplicity). Then the key swap is URF-UBR, and if we solve the left block using U L2 U' L2 U' L2 U2 L2, assuming invariance, the key swap becomes DLF-ULB. But how can the key swap involve a piece in the left block that's already solved?
 

Teoidus

Member
Joined
Feb 11, 2016
Messages
573
Location
Char
Unfortunately this gets messier once we take the edges into account. We have to do EO and get the LD/LF/LB edges out of the R layer, which probably takes around 5 moves, and we have to track CP throughout that. (Or if we leave the M slice free, we don't have to do EO, which might be better?)
Yeah, this was one of my biggest issues with the idea. Forcing left block every time alone takes some extra moves (it's more like 2-3 on average but I don't like it since it means we'd have to track every left block edge during EOLine to fully plan CP in inspection). Perhaps the best way to go about it would be to force left block while placing the corners into one of those states, but then the current method I have of detecting CP breaks down.


I don't think this works. Just because it's invariant under ⟨R,U⟩ doesn't mean it has to be invariant under every 2-gen subgroup.

This should work, though it's likely I'm not being very clear. Since any 6-corner permutation can be reduced by a single swap on U, and since any 2gen scrambling <L,U> won't change the permutation of the U layer corners wrt each other when DLF and DLB are once again solved <L,U>, any permutation of the 8 corners in which DLF and DLB are solvable <L,U> has a single swap that makes all 8 corners solvable by <L,U> and then <R,U>. This swap will be invariant under <L,U> in the sense that the same pieces (not necessarily the same positions) will need be swapped after <L,U> to solve DLF and DLB (since the only possible permutation the <L,U> business could've done given that DLF and DLB have been solved once more and that <L,U> is 2-gen group is something in <U> which of course doesn't do anything to CP wrt <R,U>)

So we take the key swap we get from tracking after we've forced left block <L,U>, and we convert it into a single swap on <L,U> that doesn't involve the DLF or DLB pieces. This swap doesn't change after solving the left block, so if we swap now then corners are solvable by <L,U> and then <R,U>, but if we solve left block <L,U> now and then swap the same pieces later (when they are on the U layer) the rest is still solvable <R,U>.

This isn't as good as the same positions need be swapped, but looking for identity of two pieces is still much better than looking at the relation between 4 i.e. Porky v2.
 
Last edited:

xyzzy

Member
Joined
Dec 24, 2015
Messages
2,878
Since any 6-corner permutation can be reduced by a single swap on U, and since any 2gen scrambling <L,U> won't change the permutation of the U layer corners wrt each other when DLF and DLB are once again solved <L,U>, any permutation of the 8 corners in which DLF and DLB are solvable <L,U> has a single swap that makes all 8 corners solvable by <L,U> and then <R,U>.

Oh! This makes a lot more sense than what I was thinking of. Yeah, this should work. I'm still not sure if there's a good way to determine the swap during inspection, though. I just tried doing a solve on an <L,U,R> scramble, and even with the EOline already done, it still took me minutes to determine the key swap. (But I'm also really bad at tracking pieces during inspection in general, bleh.)

// insp: key swap is white-red-green with yellow-red-blue
U' L' U R U2 L' U2 L2 U2 L U L' U' L // left block
L' U R2 U' L // diagonal swap
R2 U2 R2 U2 R2 U' R' U' R U // F2L on left
U' R2 U R U' R U // antisune lol


Made one R move while forming the left block, but that doesn't affect the CP state since the yellow-orange corners were on the L face and permuted relative to each other at that point. What I did for the CP recognition was to mentally solve DLF and DBL (ignoring orientation), then trace cycles to determine the swap for <R,U>; it seems like this could be reasonably fast with loads of practice.
 

Teoidus

Member
Joined
Feb 11, 2016
Messages
573
Location
Char
What I did for the CP recognition was to mentally solve DLF and DBL (ignoring orientation), then trace cycles to determine the swap for <R,U>; it seems like this could be reasonably fast with loads of practice.

Hmm. I wonder if you could mentally "solve" DLF and DBL but do so with swaps, then begin tracing with a swap that's needed to "correct for" the swaps needed to solve DLF/DBL (essentially given two swaps to solve DLF and DBL, the third swap will make the resulting permutation reachable <L,U>). Would make things logistically a bit easier; basically whenever hit DLF or DBL just trace it as if it were the piece that's currently at DLF or DBL (which simulates the swap)

Overall though I'd agree with you that this looks very complex. It would, if practiced, essentially fulfill the "missing link" of ZZ, but I'm not sure if it's worth it because there are so many moves required to force <L,U> left block and then correct CP when time comes.

I think it's still worth looking into a more general way to find and track these sorts of swaps though. If there could be a way to easily keep track of the swap while solving ZZF2L as normal (i.e. alternating between RU and LU), then reducing CP to 2gen with the first pair to complete a 1x2x3 block (either left or right is fine). Would basically be like ZZ-d except you don't have to solve left block first and no recognition step disrupting the flow of the F2L.
 
Joined
Aug 6, 2016
Messages
6
To reduce the algorithm count of pinky pie (full OLLCP), why not solve UL UR on bottom before you insert the last pair of SB, then orient the top layer edges while inserting the last pair of SB (ZBLS), solve the COLL then insert UL UR and do 4C?

I see two possible ways of reaching the net result of EO plus UL UR on bottom. The first (and to me the most plausible) way to approach this is solving UL UR on bottom after building the back square, then solve the last pair like CFOP and do ZBLS.

You could also solve the last pair of SB then place UL UR although so far I have not found a consistent way of doing this.

I don't see any big problem, of course there are some last pair EO cases that suck or you may get a bad CFOP pair (only a problem with the first way).

Any thoughts?
 

Teoidus

Member
Joined
Feb 11, 2016
Messages
573
Location
Char
Pinkie Pie really is only viable if you learn the full OLLCP sadly. The extra moves needed if you use EOLS + ULUR on bottom + COLL ends up being less efficient than normal Roux
 

TDM

Member
Joined
Mar 7, 2013
Messages
7,006
Location
Oxfordshire, UK
WCA
2013MEND03
YouTube
Visit Channel
To reduce the algorithm count of pinky pie (full OLLCP), why not solve UL UR on bottom before you insert the last pair of SB, then orient the top layer edges while inserting the last pair of SB (ZBLS), solve the COLL then insert UL UR and do 4C?

I see two possible ways of reaching the net result of EO plus UL UR on bottom. The first (and to me the most plausible) way to approach this is solving UL UR on bottom after building the back square, then solve the last pair like CFOP and do ZBLS.

You could also solve the last pair of SB then place UL UR although so far I have not found a consistent way of doing this.

I don't see any big problem, of course there are some last pair EO cases that suck or you may get a bad CFOP pair (only a problem with the first way).

Any thoughts?
Not worth it. If you're doing that you might as well insert them at the start of the solve - and then do F2B like CFOP F2L. But of course this is then just a less efficient version of ZB.
Pinkie Pie isn't supposed to be used in every solve, only where it's convenient to do so.

Also ZBLS+COLL is more algs than OLLCP, so you're not reducing the required number of algorithms. I also think that, in general, COLLs are also slower than the average OLLCP.
 

MethodNeutral

Member
Joined
Jan 4, 2017
Messages
48
I've been learning COLL in an attempt to convince myself I don't need to switch to CFOP/Fridrich (I use ZZ) and I decided to look into ELL... It turns out it's only 25 algs. So, consider a LL method with COLL/CLL first (42 algs) then ELL to finish up. It's a total of 67 algs for a 2LLL, compared to CFOP's 78. It isn't much of an improvement, but I haven't seen it mentioned anywhere. Is there an obvious flaw I'm missing?
 

obelisk477

Member
Joined
Aug 26, 2010
Messages
1,144
Location
Raleigh, NC
WCA
2009BATT01
YouTube
Visit Channel
I've been learning COLL in an attempt to convince myself I don't need to switch to CFOP/Fridrich (I use ZZ) and I decided to look into ELL... It turns out it's only 25 algs. So, consider a LL method with COLL/CLL first (42 algs) then ELL to finish up. It's a total of 67 algs for a 2LLL, compared to CFOP's 78. It isn't much of an improvement, but I haven't seen it mentioned anywhere. Is there an obvious flaw I'm missing?

What you're missing is that this has been a method almost since the dawn of speedcubing.

https://www.speedsolving.com/wiki/index.php/CFCE

EDIT: Also, there's 29, not 25. Looks like you're not counting EPLL, which is another 4
 

GenTheSnail

Member
Joined
Mar 18, 2016
Messages
2,249
Location
Illinois, USA
WCA
2016GEEN01
YouTube
Visit Channel
Is there an obvious flaw I'm missing?
As obelisk kindly pointed out, yes, it has been invented before.

One reason that CLL/ELL it isn't a main-stream method is the recognition.
OLL/PLL recognition is fairly easy, and COLL recognition is also easy. However, ELL recognition, by our current systems, is not.

It isn't much of an improvement, but I haven't seen it mentioned anywhere.
I'm not sure where you have looked, but it is a very old method that would be practically anywhere.
Please check the wiki or use the search bar before posting, anything really. The forum is >10 years old, and lots of methods have been proposed.
 

MethodNeutral

Member
Joined
Jan 4, 2017
Messages
48
What you're missing is that this has been a method almost since the dawn of speedcubing.

https://www.speedsolving.com/wiki/index.php/CFCE

EDIT: Also, there's 29, not 25. Looks like you're not counting EPLL, which is another 4
Thank you very much, I've seen CFCE listed under methods but never taken the time to look into it. Also, I'm new to the forums, so if I have a question about a method (NMLL), where would I put it? I don't even know what it stands for because all of the entries I've found on it are very short.

One reason that CLL/ELL it isn't a main-stream method is the recognition.
OLL/PLL recognition is fairly easy, and COLL recognition is also easy. However, ELL recognition, by our current systems, is not.


I'm not sure where you have looked, but it is a very old method that would be practically anywhere.
Please check the wiki or use the search bar before posting, anything really. The forum is >10 years old, and lots of methods have been proposed.
Thank you for your insight into why it isn't popular.
I couldn't find it because I wasn't sure what to search for, but I'll make sure I check next time.
 

obelisk477

Member
Joined
Aug 26, 2010
Messages
1,144
Location
Raleigh, NC
WCA
2009BATT01
YouTube
Visit Channel
Thank you very much, I've seen CFCE listed under methods but never taken the time to look into it. Also, I'm new to the forums, so if I have a question about a method (NMLL), where would I put it? I don't even know what it stands for because all of the entries I've found on it are very short.

You would post it here generally, or in the ZZ or Roux help for NMLL specifically. NMLL stands for non-matching last layer, and I recently answered a question about it here, posts 610 through 612 on that page
 
Top