# SuneLS - 1LLL system for Petrus/ZZ



## Noahaha (Feb 12, 2012)

This is really nothing special, but if you want a 1LLL, you might like it.

The concept is that you place the final pair where it can be inserted with R U' R' just like Winter Variation. WV is really awkward though, so I thought that it might be easier just to force a Sune or AntiSune ZBLL, for which you would only need 72 algorithms (if you're good at mirroring) for a 1LLL. This is what I found:

There are 4 simple ways to insert the final pair:
R U' R' (algA)
U R U2 R' (algB)
R U R' U' R U' R' (algC)
U R U' R' U R U2 R' (algD)

Out of the 27 corner cases,
6 - use algA to force a Sune or AntiSune ZBLL
1 - uses algA to reach PLL
5 - use algB to force a Sune or AntiSune ZBLL
1 - uses algB to reach PLL
3 - use algC to force a Sune or AntiSune ZBLL
1 - uses algC to reach PLL
3 - use algD to force a Sune or AntiSune ZBLL
1 - uses algD to reach PLL

This only covers 21 of the cases though. The remaining 6 cannot reach a PLL or Sune ZBLL using A, B, C or D, so there are a few options:
1. Use one of the following three algs:
algE: R U' R' U' R U R' U R U2 R'
algF: R U' R2 U' R U R' U R U2 R'
algG: R U' R U' R U R' U R U2 R'
These simply insert the pair and then apply a Sune to reach a Sune or AntiSune position.

2. Use your knowledge of the corner case to predict what OCLL it will be. So just apply case A and then without having to look apply an OCLL.

3. Use the WV case.

4. Also learn the Pi ZBLLs, as all 6 of these tricky positions can reach the Pi OCLL very easily.

5. Predict these cases earlier on in order to avoid them.

I think option 3 is the best, since 4 is just not worth it while 1 and 2 are not as efficient and option 5 would be very difficult since there is nothing very distinctive about these six cases.

I think that if someone got fast enough at the ZBLLs required, this is a pretty feasible 1LLL possibility, especially since the slowest of the 4 ways to insert the pair (algD) can be done in less than half a second.

If people are interested, I'll post my findings concerning which insert to use in which cases. 

DISCLAIMER: I don't know much about ZBLL.

Can someone at least tell me how difficult the Sune/AntiSune cases for ZBLL are before I start learning them?


----------



## 5BLD (Feb 12, 2012)

I had an idea to do this a while back, with Petrus. Although tbh some Sune ZBLLs are awkward to execute. I prefer to force a U/T case. 

I didn't follow through with it though because I didn't even know a quarter ZBLL at that time.

As for recognition it's easy-peasy. COLL recognition with EPLL, becomes looking for pairs around the edges of the U layer.


----------



## Noahaha (Feb 12, 2012)

5BLD said:


> Although tbh some Sune ZBLLs are awkward to execute.



Well all my PLLs are pretty awkward, so I think I'll start learning this. Even if I can't get it right for speedsolving, it'll still be cool to solve any Sune position with one algorithm.


----------



## Forte (Feb 13, 2012)

Have you seeeeen [wiki]ZZ-blah[/wiki]?


----------



## Noahaha (Feb 13, 2012)

Forte said:


> Have you seeeeen [wiki]ZZ-blah[/wiki]?


 
Yes I have!
I think I'd rather learn this though since it uses less algorithms. Also, I feel like more cases naturally reach Sune than any position with disoriented corners. I'm not trying to say that this is very original, just that it is an idea for people who want a 1LLL.

EDIT: I just tested a few of the cases, and my suspicions were confirmed. using my 4 "algs" it appears to be easier to reach a Sune than a Pi/H.


----------



## Tim Reynolds (Feb 13, 2012)

I don't think this would be worth it. Sune ZBLL recognition is probably slower than doing a Sune. If you were to do this, I think you should just force a sune, do a sune, then do a PLL.

Also, WV isn't that bad.


----------



## Noahaha (Feb 13, 2012)

Tim Reynolds said:


> I don't think this would be worth it. Sune ZBLL recognition is probably slower than doing a Sune. If you were to do this, I think you should just force a sune, do a sune, then do a PLL.
> 
> Also, WV isn't that bad.


 
Are you sure that recognition for this couldn't be as fast as PLL recognition with enough practice? Because right now it's seeming really appealing to me, especially since I despise PLL. Also, Average movecount for this is like 13 moves, which is shorter than J-perm.


----------



## RNewms27 (Feb 13, 2012)

Noahaha said:


> Are you sure that recognition for this couldn't be as fast as PLL recognition with enough practice? Because right now it's seeming really appealing to me, especially since I despise PLL. Also, Average movecount for this is like 13 moves, which is shorter than J-perm.


 
13 moves is J-perm.


----------



## Noahaha (Feb 13, 2012)

RNewms27 said:


> 13 moves is J-perm.


 
Oops. I counted the AUF.


----------



## Forte (Feb 13, 2012)

Noahaha said:


> Are you sure that recognition for this couldn't be as fast as PLL recognition with enough practice? Because right now it's seeming really appealing to me, especially since I despise PLL. Also, Average movecount for this is like 13 moves, which is shorter than J-perm.


 
Just about the movecount argument:
If 13 HTM is optimal there, then we should probably consider optimal PLLs, so J perm is 10 HTM.


----------



## Noahaha (Feb 13, 2012)

Forte said:


> Just about the movecount argument:
> If 13 HTM is optimal there, then we should probably consider optimal PLLs, so J perm is 10 HTM.


 
I guess you're right.
I'm probably going to try out this system for a little while. At the very least I've found a way to make OCLL very quick. The one thing I'm worried about is the mirroring, but I could probably get used to it. Is there anyone who thinks that it would be a complete waste of time?


----------



## RNewms27 (Feb 13, 2012)

It's not a waste if you're learning.


----------



## Forte (Feb 13, 2012)

Noahaha said:


> I guess you're right.
> I'm probably going to try out this system for a little while. At the very least I've found a way to make OCLL very quick. The one thing I'm worried about is the mirroring, but I could probably get used to it. Is there anyone who thinks that it would be a complete waste of time?


 
I do, but I always spend time learning random stuff that's not useful, so I'm not one to talk lol


----------



## oll+phase+sync (Feb 15, 2012)

Tim Reynolds said:


> ... If you were to do this, I think you should just force a sune, do a sune, then do a PLL.


 
that means if I didn't learn all Sune / Antisune ZBLLs I still have an benefit.

zz-blah needs 108 algs (usign Pi and H ) in my opinion the number of algs for ( Sune / AntiSune) should be higher than that ?


----------



## Noahaha (Feb 15, 2012)

oll+phase+sync said:


> that means if I didn't learn all Sune / Antisune ZBLLs I still have an benefit.
> 
> zz-blah needs 108 algs (usign Pi and H ) in my opinion the number of algs for ( Sune / AntiSune) should be higher than that ?


 
Well Sune is 72 algs and can be mirrored to AntiSune. I've actually scrapped the ZBLL idea and I'm working on a new one with a similar premise. My goal is that from any last slot case, I'll be able to force a Sune AND predict what the Sune will be. This results in very fast 2-gen last slot + OLL solutions without learning any algorithms. The only unfortunate part is that I will have to be able to recognize 27 cases for each last slot situation, where for each case I need to remember how I should insert the pair, what the AUF is, and whether it's a Sune or an Antisune. I don't think it will be too bad though, since it's all case recognition with no algorithm memorization.


----------



## JLarsen (Feb 16, 2012)

Haha that sounds pretty cool. Constant sunes all the time. I'd like to hear something about the movecounts for this approach vs. traditional last slotting / OLL. 

Oh, I've got a question I don't think anybody has answered for me yet - all these last slot methods accommodate both the FR and BR slots, right? When I use the I/IM MGLS sets I can just rotate the back slot into the FR position and I'm good. Does the same thing still apply with this? How about winter variation? Other approaches?


----------



## Noahaha (Feb 17, 2012)

JLarsen said:


> Haha that sounds pretty cool. Constant sunes all the time. I'd like to hear something about the movecounts for this approach vs. traditional last slotting / OLL.
> 
> Oh, I've got a question I don't think anybody has answered for me yet - all these last slot methods accommodate both the FR and BR slots, right? When I use the I/IM MGLS sets I can just rotate the back slot into the FR position and I'm good. Does the same thing still apply with this? How about winter variation? Other approaches?



Movecounts are just a little bit better than normal as long as you're ok not getting Sune for the 6 bad cases. The only difficulty will be for recognition when it comes to cases other than Winter and Summer variations. You basically just have to know ALL the transpositions, so the last slot is recognized in two steps: 
1 - recognize the corner - edge pairing case
2 - look at the orientations of the three U layer corners in the toplayer and determine what "Winter Variation" case it will transpose to. 
Then, just like the cases where they're already paired, you choose an insert and execute a Sune (or another OLL if it's one of the 6 bad cases).
The verdict is that movecounts are good but recognition is not wonderful. If I get fast with this, I'll let you know.

As for your question, which I already answered in the Petrus Home Thread, the answer is yes, as long as the final edge is placed. A y rotation will only disrupt your good and bad edges if a U layer edge is in the last slot. 

Also, I'm working on something kinda like the Xcross in Fridrich, which I call a CPblock. It's exactly what it sounds like. I've found that if you can permute the corners during the 2x2x2, it's not terribly difficult to KEEP THE CORNERS PERMUTED during the extension to 2x2x3 and EO, resulting in a 2GLL 1LLL. The difficulty is that I need like three minutes of inspection to plan a CPblock.

Anyway, I'll tell you if any of these experiments start looking promising.


----------



## JLarsen (Feb 17, 2012)

Really interesting stuff man. Good luck and I hope you come across something useful.


----------



## oll+phase+sync (Feb 17, 2012)

Noahaha said:


> ... if you can permute the corners during the 2x2x2, it's not terribly difficult to KEEP THE CORNERS PERMUTED during the extension to 2x2x3 and EO, resulting in a 2GLL 1LLL.



Have you already a rule for: 

What is 'correct' corner permutation after doing a 2x2x2? 

What moves are allowed to extend the 2x2x2 to a 2x2x3, while preserving correct corner permutation ? 


P.S. Cool answers to this questions will make for a new ZZ-d style 2x2x2 method.


----------



## PhillipEspinoza (Feb 17, 2012)

Just do CPLS + 2GLL. It's not *entirely* bad. 

ORR you can do what I've been toying around with that's CFOP friendly. EOCPLL + 2GLL. Not that many cases and OH friendly cases. Recog is easy once you get it down. I thought about pursuing this when I was toying with OCPLL.


----------



## Kirjava (Feb 17, 2012)

PhillipEspinoza said:


> Just do CPLS + 2GLL. It's not *entirely* bad.


 
I hear that OLL/PLL has potential, too.


----------



## Noahaha (Feb 17, 2012)

oll+phase+sync said:


> Have you already a rule for:
> 
> What is 'correct' corner permutation after doing a 2x2x2?
> 
> ...


 
Correct corner permutation after the 2x2x2 is when all the corners are in the right spots. You can then do the normal three move edge inserts without disrupting corner permutation. The only annoying part comes in EO where you want to have 0 or 4 bad edges since M' U M and M U M' are the Easiest edge flips that don't screw up your CP. This is actually not hard to force if you're good at influencing EO while inserting edges for the 2x2x3. The way I see it right now, the only hard part is going to be finding an efficient way to see a CPblock solution during inspection.


----------

